https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #1 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
> This is because IRA does
>
> r125: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS
>
> a1(r125,l0) costs: BASE_REGS:14004,14004 GENERAL_REGS:14004,14004-
> LINK_REGS:24010,24010 CTR_REGS:24010,24010 LINK_OR_CTR_REGS:24010,24010-
> SPEC_OR_GEN_REGS:24010,24010 MEM:12000,12000
>
> and it then chooses disposition mem for r125.
>
> In GCC 8 and before combine already has decided to use GPR3 (the first
> argument register) for this, so there was no RA here before.
The very first ira-costs pass runs in sched1 and it generates the following
costs
r125 costs: BASE_REGS:10000 GENERAL_REGS:10000 LINK_REGS:20000 CTR_REGS:20000
LINK_OR_CTR_REGS:20000 SPEC_OR_GEN_REGS:20000 MEM:8000
The costs in IRA are bit different because we calculate costs knowing our
preference for p125 as NO_REGS.
Why does IRA calculate such costs? We have 2 insns involving p125
15: r125:DI=%3:DI
REG_DEAD %3:DI
7: {r123:SI=asm_operands/*r125 with constraint 'v'*/;clobber ca:SI;}
Cost of moving r3 into p125 is 2 for base regs and 4 for memory
Cost of moving p125 into a v reg is 8 for base regs and 4 for memory
Therefore cost of p125 is 10 for base reg and 8 for memory (multiplied by BB
frequency 10000).
Therefore IRA chooses memory for p125.
In this particular case insn 15 can go away when we assign r3 to p125. It
means the cost for base reg could be 8 as for memory but IRA can not say in
general case that it can assign r3 to p125.
I think increasing memory move cost at least to 5 could solve the problem. But
probably it needs benchmarking SPEC, besides running GCC testsuite, to see that
the performance is not worse after such change.
