[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92

["roger at nextmovesoftware dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #3 from Roger Sayle <roger at nextmovesoftware dot com> ---
Ignore all of Comment 2.  The reason the instruction isn't getting split, is
that (unlike the other clones), the pseudo's mode is V1TI (not TI), hence
doesn't match the <DWI> constraint.  The problem is STV (again), where uses of
a pseudo are split into different chains, and some chains are considered
profitable, and other chains aren't supported in V1TImode.

Searching for mode conversion candidates...
  insn 13 is marked as a TImode candidate
  insn 16 is marked as a TImode candidate
Created a new instruction chain #7
Building chain #7...
  Adding insn 13 to chain #7
Collected chain #7...
  insns: 13
Computing gain for chain #7...
  Instruction gain 4 for    13: [r91:DI]=r82:TI
      REG_DEAD r91:DI
  Total gain: 5
Converting chain #7...
deferring rescan insn with uid = 13.
Created a new instruction chain #8
Building chain #8...
  Adding insn 16 to chain #8
Collected chain #8...
  insns: 16
Computing gain for chain #8...
  Instruction gain -4 for    16: flags:CCZ=cmp(r82:V1TI,0x1)
      REG_DEAD r82:V1TI
  Total gain: -3
Chain #8 conversion is not profitable
Total insns converted: 1


The issue is that you can't convert insn 13 to V1TImode if you don't convert
insn 16, i.e. all uses of a pseudo should have the same mode.  [Calling
PUT_MODE on the first use, implicitly updates the second].  I believe (this
time) that the uninitialized value from "empty()" confuses that DF analysis,
and insns 13 and 16 end up on different (dependency) chains, because the lack
on initialization makes them look independent.