Richard Biener <richard.guent...@gmail.com> writes: > On Wed, May 10, 2023 at 12:05 AM Richard Sandiford via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: >> >> Andrew Pinski <pins...@gmail.com> writes: >> > On Tue, May 9, 2023 at 11:02 AM Richard Sandiford via Gcc-patches >> > <gcc-patches@gcc.gnu.org> wrote: >> >> >> >> REG_ALLOC_ORDER is much less important than it used to be, but it >> >> is still used as a tie-breaker when multiple registers in a class >> >> are equally good. >> > >> > This was tried before but had to be reverted. I have not looked into >> > the history on why though. >> > Anyways it was recorded as https://gcc.gnu.org/PR63521. >> >> It looks like that was about the traditional use of REG_ALLOC_ORDER: >> putting call-clobbered registers first and defining >> HONOR_REG_ALLOC_ORDER to make order trump IRA's usual costing. >> We definitely don't want to do that, for the reasons described in the >> patch and that Richard gave in comment 2. (IRA already accounts for >> call-preservedness. It also accounts for conflicts with argument >> registers, so putting those in reverse order shouldn't be necessary.) >> >> The aim here is different: to keep REG_ALLOC_ORDER as a pure tiebreaker, >> but to avoid eating into restricted FP register classes when we don't >> need to. > > I wonder if IRA/LRA could do this on its own - when a register belongs > to multiple > register classes and there's choice between two being in N and M register > classes prefer the register that's in fewer register classes? I mean, > that's your > logic - choose a register that leaves maximum freedom of use for the remaining > registers?
Yeah, I wondered about that. But the problem is that targets tend to define classes for special purposes. E.g. aarch64 has TAILCALL_ADDR_REGS, which contains just x16 and x17. But that class is only used for the address in an indirect sibling call. Something that niche shouldn't affect the allocation of ordinary GPRs. I also think it would be hard for a target-independent algorithm to do a good job with the x86 register classes. So in the end it seemed like some target-dependent knowledge was needed to determine which classes are important enough and which aren't. Thanks, Richard
