https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > So for which pseudo and which hard register did this ICE, and what did the
> > code look like at that point?
>
> The culprit pseudo is r133, the values of those related expressions in the
> check:
>
> lra_reg_info[i].nrefs -> 4
>
> reg_renumber[i] -> 97
>
> overlaps_hard_reg_set_p(lra_reg_info[i].conflict_hard_regs, E_SImode, 97) ->
> true
>
> Before IRA, the code looks like:
> (insn 34 33 35 4 (set (reg:SI 97 ctr)
> (reg/v/f:SI 133 [ foo ])) "test.f":17:72 562 {*movsi_internal1}
> (nil))
> in IRA, the hard reg assignment is:
> choosing r3 for r133.
Doing ctr (reg 97) instead (as LRA seems to change it to?) is
counterproductive.
We have that
> (insn 33 32 34 4 (set (reg:SI 3 3)
> (reg/v/f:SI 137 [ g ])) "test.f":17:72 562 {*movsi_internal1}
> (nil))
right before 34, so if we want to use hard reg 3 for pseudo 97 we could
swap insns 33 and 34 (both of which are trivial assignments), much nicer
than the current dance via memory.
But all of this is a distraction from the actual bug here, sorry.
