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.