https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70961
--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > 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). That's not what the hook was initially designed for, as implied by its name. > 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. That's why the superunion was chosen. If all the patterns are LO_REGS, it will be LO_REGS; likewise for HI_REGS. It's GENERAL_REGS only when there is a mixed bag of them. > 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... So what happens if you block the second pass with a special class value?
