https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124439
--- Comment #4 from Robin Dapp <rdapp at gcc dot gnu.org> ---
We have
(insn 11 156 12 2 (set (reg/f:DI 244)
(plus:DI (reg/f:DI 65 frame)
(const_int -80 [0xffffffffffffffb0]))) "a-tigeli.adb":84:7 5
{*adddi3}
(expr_list:REG_EQUIV (plus:DI (reg/f:DI 65 frame)
(const_int -80 [0xffffffffffffffb0]))
(nil)))
and in lra we delete it
Can eliminate 65 to 8 (offset=-32, prev_offset=-1)
Removing equiv init insn 11 (freq=1000)
11: r244:DI=frame:DI
REG_EQUIV frame:DI-0x50
deleting insn with uid = 11.
and replace all uses of r244 with the equivalence.
In the good case, this also happens for insn 105, in the bad case it doesn't
and r244 stays.
As we deleted r244's definition (insn 11) the following reload
Creating newreg=251 from oldreg=244, assigning class GR_REGS to r251
Inserting insn reload before:
165: r251:DI=r244:DI
doesn't make sense because the spill slot is uninitialized.
So when deleting insn 11 we assume that all uses will be replaced. The way
it's written, I suppose that's a basic assumption of lra.
In that light, it's questionable if my fix for PR124041 was correct. A
different interpretation could be that, with the frame pointer being
eliminable, should be allowed to survive in subreg contexts despite
hard_regno_mode_ok.
But then, we should also actually eliminate it before running into problems.
I'll try to look around, maybe there's another way of fixing PR124041. If I
don't get anywhere, it sounds like a job for Vlad.
