https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93611
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:e7bec5d5edeaab404931bf599821c6c2a3023b47 commit r10-6498-ge7bec5d5edeaab404931bf599821c6c2a3023b47 Author: Jakub Jelinek <ja...@redhat.com> Date: Fri Feb 7 09:26:54 2020 +0100 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 <ja...@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.
