https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116390
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |14.1.0
Summary|Another ICE for avrtiny and |[ext_dce][avr][15
|optimization |regression]Another ICE for
| |avrtiny and optimization
Status|UNCONFIRMED |NEW
Last reconfirmed| |2024-08-17
Component|target |rtl-optimization
Ever confirmed|0 |1
CC| |law at gcc dot gnu.org
--- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
This seems to be a bug in ext_dce, and it can be worked around with
-fno-ext-dce.
>From .expand, there is this insn:
(insn 27 26 0 (set (reg/v:SI 60 [ n2 ])
(zero_extend:SI (reg/v:HI 63 [ n1 ]))) "pr116390-i.cpp":33:20 -1
(nil))
which .ext_dce turns into a paradoxical subreg:
Processing insn:
27: r60:SI=zero_extend(r63:HI)
REG_DEAD r63:HI
Trying to simplify pattern:
(zero_extend:SI (reg/v:HI 63 [ n1 ]))
rescanning insn with uid = 27.
Successfully transformed to:
(subreg:SI (reg/v:HI 63 [ n1 ]) 0)
This paradoxical subreg it there until register allocation, which turns the
insn into
(insn 27 145 28 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 7 [0x7])) [4 %sfp+7 S4 A8])
(reg:SI 26 r26)) "pr116390-i.cpp":33:20 119 {*movsi_split}
(nil))
and this is complete rubbish because R26:SI overlaps with the frame pointer
R28:HI.
Apart from that, representing a zero_extend as a paradoxical subreg is spoiling
all respective combine patterns that combine shifts with zero_extends. Are we
supposed to rewrite all of them using paradoxical subregs?
