https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
--- Comment #13 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (In reply to Jeffrey A. Law from comment #12) > > One of the things I notice is that LRA is generating sequences like: > (insn 581 89 90 6 (set (reg:SI 3 bx [107]) > (mem/c:SI (plus:SI (reg/f:SI 7 sp) > (const_int 28 [0x1c])) [4 %sfp+-4 S4 A32])) j.c:19 90 > {*movsi_internal} > (nil)) > (insn 90 581 91 6 (set (reg/f:SI 3 bx [orig:142 D.2145 ] [142]) > (mem/f/c:SI (plus:SI (reg:SI 3 bx [107]) > (const:SI (unspec:SI [ > (symbol_ref:SI ("out") [flags 0x2] <var_decl > 0x7ffff670bc60 out>) > ] UNSPEC_GOTOFF))) [1 out+0 S4 A32])) j.c:19 90 > {*movsi_internal} > (nil)) > > Note how we load %ebx from memory, then use/clobber it in the next insn. > That makes it impossible for the post-reload optimizers to help clean this > up. How hard would it be to generate code in LRA where those two insns set > different registers in those local snippets of code? > > In this particular case, %ebp is locally available and there's no strong > reason why we have to use %ebx. By using different destinations for insns > 581 and 90, the source MEM of insn 581 would be available after insn 90. > And by making the value available postreload-gcse would be able to commonize > those loads. Jeff, thanks for the analysis. PIC pseudo really can be in different regs. There are a lot of places in RA in what reg the pic pseudo will be placed for particular live range. Probably there is a place where the decision is done for ebx without considering other alternatives. I'll investigate this problem.