https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
--- Comment #10 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (In reply to Alan Modra from comment #9) > So, what's happening here on the testcase is that before r210519, from the > ira dump for pseudo reg 171 we have > > a15 (r171,l0) best GENERAL_REGS, allocno GENERAL_REGS > > a15(r171,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 > NON_SPECIAL_REGS:3264,3264 LINK_REGS:1224,1224 CTR_REGS:1224,1224 > LINK_OR_CTR_REGS:1224,1224 SPECIAL_REGS:1224,1224 SPEC_OR_GEN_REGS:1224,1224 > NON_FLOAT_REGS:4896,4896 ALL_REGS:4896,4896 MEM:0,0 > > and after > > a15 (r171,l0) best NO_REGS, allocno NO_REGS > > a15(r171,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 > NON_SPECIAL_REGS:1224,1224 LINK_REGS:1224,1224 CTR_REGS:1224,1224 > LINK_OR_CTR_REGS:1224,1224 SPECIAL_REGS:1224,1224 SPEC_OR_GEN_REGS:1224,1224 > NON_FLOAT_REGS:2448,2448 ALL_REGS:2448,2448 MEM:-320,-320 > > (hmm, negative cost, is that really allowed??) > > Yes, it is allowed. It might be a saving. For example, if you have insn loading pseudo from a equivalent memory. Assigning the equivalent memory will remove the insn. There is also a discrepancy between LRA and reload in many cases (e.g. in treatment constraints with only 'm'). The patch which triggered the bug was for x86 using LRA. PPC is using reload by default. I guess switching to LRA would remove some future troubles.
