i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]
authorJakub Jelinek <jakub@redhat.com>
Mon, 10 Feb 2020 21:44:40 +0000 (22:44 +0100)
committerJakub Jelinek <jakub@redhat.com>
Mon, 10 Feb 2020 21:44:40 +0000 (22:44 +0100)
commitf57aa9503ff170ff6c8549718bd736f6c8168bab
tree32c89edb90d99d0437a1214b3cf0db01f12bba28
parent41a9e940c7014f117738a9a59b31833047a1083d
i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

As mentioned in the PR, for -mavx -mno-avx2 the backend does support
vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors
aren't much supported in that case, it is performed using
vandps/vandnps/vorps).  The problem is that after the last generic vector
lowering (where the VEC_COND_EXPR still compares two V4DF vectors and
has two V4DI last operands and V4DI result and so is considered ok) fre4
folds the condition into constant, at which point the middle-end during
expansion will try vcond_mask_optab and fall back to trying to expand it
as the constant vector < 0 vcondv4div4di, but neither of them is supported
for -mavx -mno-avx2 and thus we ICE.

So, the options I see is either what the following patch does, also support
vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or
require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current
TARGET_AVX.

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

PR target/93637
* config/i386/sse.md (VI_256_AVX2): New mode iterator.
(vcond_mask_<mode><sseintvecmodelower>): Use it instead of VI_256.
Change condition from TARGET_AVX2 to TARGET_AVX.

* gcc.target/i386/avx-pr93637.c: New test.
gcc/ChangeLog
gcc/config/i386/sse.md
gcc/testsuite/ChangeLog
gcc/testsuite/gcc.target/i386/avx-pr93637.c [new file with mode: 0644]