[Bug target/94308] [10 Regression] ICE in final_scan_insn_1 with vzeroupper since r10-6451
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Mar 25 10:40:42 GMT 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94308
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:d5ad8ee04a78b576867fd78b2f25201ea6b4aae1
commit r10-7373-gd5ad8ee04a78b576867fd78b2f25201ea6b4aae1
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed Mar 25 11:40:00 2020 +0100
i386: Fix ix86_add_reg_usage_to_vzeroupper [PR94308]
The following patch ICEs due to my recent change r10-6451-gb7b3378f91c.
Since that patch, for explicit vzeroupper in the sources (when an intrinsic
is used), we start with the *avx_vzeroupper_1 pattern which contains just
the
UNSPECV_VZEROUPPER and no sets/clobbers. The vzeroupper pass then adds
some
sets to those, but doesn't add clobbers and finally there is an
&& epilogue_completed splitter that splits this into the *avx_vzeroupper
pattern which has the right number of sets/clobbers (16 on 64-bit, 8 on
32-bit) + the UNSPECV_VZEROUPPER first.
The problem with this testcase on !TARGET_64BIT is that the vzeroupper pass
adds 8 sets to the pattern, i.e. the maximum number, but INSN_CODE stays
to be the one of the *avx_vzeroupper_1 pattern. The splitter doesn't do
anything here, because it sees the number of rtxes in the PARALLEL already
the right count, but during final we see that the *avx_vzeroupper_1 pattern
has "#" output template and ICE that we forgot to split it.
The following patch fixes it by forcing re-recognition of the insn after we
make the changes to it in ix86_add_reg_usage_to_vzeroupper. Anything that
will call recog_memoized later on will recog it and find out it is in this
case already *avx_vzeroupper rather than *avx_vzeroupper_1.
2020-03-25 Jakub Jelinek <jakub@redhat.com>
PR target/94308
* config/i386/i386-features.c (ix86_add_reg_usage_to_vzeroupper):
Set
INSN_CODE (insn) to -1 when changing the pattern.
* gcc.target/i386/pr94308.c: New test.
More information about the Gcc-bugs
mailing list