https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70961
--- Comment #3 from Wilco <wdijkstr at arm dot com> --- (In reply to Eric Botcazou from comment #2) > Pass #2 ignores it since the preference simply couldn't be honored. In which case it should not rename that chain rather than just ignore the preference (and a preference of NO_REGS should probably also block renaming). > > The super_class has nothing to do with the class that is searched for > > renaming registers though, it's just the info passed to the back-end to > > compute this class. For example, on the ARM, the preferred_class will be > > LO_REGS for any chain of GENERAL_REGS. Actually for a chain of GENERAL_REGS the preferred class should be GENERAL_REGS - using LO_REGS in that case would be counterproductive. You'd prefer LO_REGS only when *some* of the patterns in a chain are LO_REGS. But since the callback only ever sees the union of all classes in a chain, I don't think could make the correct decision. > As a matter of fact, that might not be true, something like > > + if (TARGET_THUMB2 && reg_class_subset_p (rclass, GENERAL_REGS)) > return LO_REGS; I tried something similar, as well as always returning LO_REGS or NO_REGS, but this makes no difference at all due to pass 2 ignoring the preference...
