[Bug rtl-optimization/116389] [avr][15 regression] ICE in extract_constrain_insn for avrtiny and -O2

["gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |law at gcc dot gnu.org
   Last reconfirmed|                            |2024-08-17
            Summary|ICE in                      |[avr][15 regression] ICE in
                   |extract_constrain_insn for  |extract_constrain_insn for
                   |avrtiny and -O2             |avrtiny and -O2
           Keywords|                            |ra
             Blocks|                            |56183
          Component|target                      |rtl-optimization

--- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
There is this insn from ext-dce (from -fdump-rtl-ira-details):

(insn 180 179 181 26 (set (reg/v:SI 70 [ __paddec ])
        (subreg:SI (reg/v:HI 78 [ __len ]) 0))
"/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/include/bits/locale_facets_nonio.tcc":477:14
119 {*movsi_split}
     (nil))

Register allocation then assigns R30:HI to pseudo 78, but due to the
paradoxical subreg, this becomes R30:SI which is not a valid hard register
because R31 is the last valid general-purpose register.  The reload dump (from
-fdump-rtl-reload-details):

(insn 180 900 181 27 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
                (const_int 28 [0x1c])) [91 %sfp+28 S4 A8])
        (reg:SI 30 r30))
"/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/inclu

This insn is not valid because R30:SI is not a valid hard reg, so it's no
wonder no valid insn constraint alternative is found and hence ICE.

So the question is whether that paradoxical subreg from ext-dce is valid in the
first place? Or is it a register allocation issue?

As an aside, -mlra also ICEs because the code is too complicated for LRA
(doesn't find reloads.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation