[Bug target/93611] [10 Regression] ICE in extract_constrain_insn_cached, at recog.c:2207 since r10-6451-gb7b3378f91c0641f

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 47788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47788&action=edit
gcc10-pr93611.patch

Ugh, this is nasty.  The problem is that splitting works by clearing
recog_data.insn and then performing various recog_data.operand elt changes,
trying to match various splitters.  That works fine, because if somebody does
extract_insn_cached afterwards, it will not use cache and will extract it
again.
The problem is that two of the i386.md splitters have conditions that
ultimately call extract_insn_cached, so if we are unlucky, try to match
splitter with that condition (which sets recog_data.insn to the current
instruction), that condition fails and we continue looking for further matching
splitters, we modify recog_data.operand again, but the generated split_insns
doesn't expect something modifies recog_data.insn.  So, when after splitting
some other pass performs extract_insn_cached, it can see a match, but
recog_data.operand array contains garbage from the failed attempts to split,
yet recog_data.insn says it is correct.