[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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at nextmovesoftware dot com

--- Comment #2 from Roger Sayle <roger at nextmovesoftware dot com> ---
Something very odd is going on.  foo.simdclone.2 contains a *cmpti_doubleword
instruction, that is defined using define_insn_and_split to be split
pre-reload.
For some reason, this isn't getting split during the split1 pass, but continues
through reload until things finally fail in cprop_hardreg.  Interestingly the
corresponding instruction is correctly split in simdclone.0 and simdclone.1.

The .293e.split1 file contains (much redacted)...

;; Function foo.simdclone.0
Splitting with gen_split_2 (i386.md:1511)
deleting insn with uid = 16.

;; Function foo.simdclone.1
Splitting with gen_split_2 (i386.md:1511)
deleting insn with uid = 22.

;; Function foo.simdclone.2

i.e. no splits are performed on foo.simdclone.2, but they are on simdclone.0
and simdclone.1.  Perhaps an off-by-one error?  I'll investigate further, but I
doubt this is an issue in the i386.md machine description; the ((simd))
attribute is interacting strangely with the split pass.