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.
