i386: Fix splitters that call extract_insn_cached [PR93611]

The following testcase ICEs.  The generated split_insns starts
with recog_data.insn = NULL and then tries to put various operands into
recog_data.operand array and checks various splitter conditions.
The problem is that some atom related tuning splitters indirectly call
extract_insn_cached on the insn they are used in.  This can change
recog_data.operand, but most likely it will just keep it as is, but
sets recog_data.insn to the current instruction.  If that splitter doesn't
match, we continue trying some other split conditions and modify
recog_data.operand array again.  If even that doesn't find any usable
splitter, we punt, but at that point recog_data.insn says that recog_data
is valid for that particular instruction, even when recog_data.operand array
can be anything.
The safest thing would be to copy whole recog_data to a temporary object
before doing the calls that can call extract_insn_cached and restore it
afterwards, but it would be also very costly, recog_data has 1280 bytes.
So, this patch just makes sure to clear recog_data.insn if it has changed
during the extract_insn_cached call, which means if we extract_insn_cached
later, we'll extract it properly, while if we call it say from some other
context than splitter conditions, the insn is already cached, we don't reset
the cache.

2020-02-07  Jakub Jelinek  <jakub@redhat.com>

	PR target/93611
	* config/i386/i386.c (ix86_lea_outperforms): Make sure to clear
	recog_data.insn if distance_non_agu_define changed it.

	* gcc.target/i386/pr93611.c: New test.

0 files changed, 0 insertions, 0 deletions