[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f57aa9503ff170ff6c8549718bd736f6c8168bab commit r10-6565-gf57aa9503ff170ff6c8549718bd736f6c8168bab Author: Jakub Jelinek Date: Mon Feb 10 22:44:40 2020 +0100 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 PR target/93637 * config/i386/sse.md (VI_256_AVX2): New mode iterator. (vcond_mask_): Use it instead of VI_256. Change condition from TARGET_AVX2 to TARGET_AVX. * gcc.target/i386/avx-pr93637.c: New test.
[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
--- Comment #5 from Jakub Jelinek ---
It is a blend, so yes, it can be represented as VEC_PERM_EXPR, or using
vcond_mask_optab etc.
The trouble is that TARGET_AVX && !TARGET_AVX2 is really weird when 32-byte
integral modes are involved and the question is what the middle-end should try
as a fallback if it sees the vcond{,u} failing when the condition is constant.
Because VEC_PERM_EXPR is said not to be supported:
typedef long long __v4di __attribute__((vector_size (32)));
__v4di
foo (__v4di z, __v4di u)
{
return __builtin_shuffle (z, u, (__v4di) { 0, 1, 6, 3 });
}
with -mavx this is lowered during veclower.
I'd say we either should enable vcond_mask* even for V4DI/V8SI, or disable
vcond{v4div4df,v8siv8sf} for !TARGET_AVX2 && TARGET_AVX.
Untested patch to do the former fixes the ICE:
--- gcc/config/i386/sse.md.jj 2020-02-10 13:14:02.970131692 +0100
+++ gcc/config/i386/sse.md 2020-02-10 13:14:43.689525366 +0100
@@ -3430,13 +3430,19 @@ (define_expand "vcond_mask_ 3 "register_operand")))]
"TARGET_AVX512BW")
+;; As vcondv4div4df and vcondv8siv8sf are enabled already with TARGET_AVX,
+;; and their condition can be folded late into a constant, we need to
+;; support vcond_mask_v4div4di and vcond_mask_v8siv8si for TARGET_AVX.
+(define_mode_iterator VI_256_AVX2 [(V32QI "TARGET_AVX2") (V16HI "TARGET_AVX2")
+ V8SI V4DI])
+
(define_expand "vcond_mask_"
- [(set (match_operand:VI_256 0 "register_operand")
- (vec_merge:VI_256
- (match_operand:VI_256 1 "nonimmediate_operand")
- (match_operand:VI_256 2 "nonimm_or_0_operand")
+ [(set (match_operand:VI_256_AVX2 0 "register_operand")
+ (vec_merge:VI_256_AVX2
+ (match_operand:VI_256_AVX2 1 "nonimmediate_operand")
+ (match_operand:VI_256_AVX2 2 "nonimm_or_0_operand")
(match_operand: 3 "register_operand")))]
- "TARGET_AVX2"
+ "TARGET_AVX"
{
ix86_expand_sse_movcc (operands[0], operands[3],
operands[1], operands[2]);
[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
--- Comment #4 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #3)
> _80 = VEC_COND_EXPR <{ -1, -1, 0, -1 }, { 5, 6, 7, 8 }, _28>;
Isn't a constant argument 0 for VEC_COND_EXPR really a VEC_PERM?
[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
--- Comment #3 from Jakub Jelinek ---
The problem is that with -mavx -mno-avx2, we have vcondv4div4df optab, but not
vcondv4div4di. Before fre4 we have:
vect_cst__5 = { 0.0, 0.0, 1.0e+0, 0.0 };
...
_55 = [0] + 32;
MEM [(double *)_55] = vect_cst__5;
...
vect_cst__49 = { 0.0, 0.0, 0.0, 0.0 };
...
vectp_ev.9_29 = + 32;
...
vect__1.11_77 = MEM [(double *)vectp_ev.9_29];
...
_80 = VEC_COND_EXPR ;
which fre4 optimizes into:
_80 = VEC_COND_EXPR <{ -1, -1, 0, -1 }, { 5, 6, 7, 8 }, _28>;
but with the comparison in VEC_COND_EXPR simplified into a constant all traces
of the V4DF are gone, and this is after the last veclower pass.
[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'll have a look.
[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-09 CC||jakub at gcc dot gnu.org Target Milestone|--- |9.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r10-1305-gbab9de71b45df56e3ad90aa817d7e23ea79d726d.
