[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 Richard Biener changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #12 from Richard Biener --- *** Bug 97239 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:fddc7f0080f1f056c4d145451608ebd3e807422a commit r11-5364-gfddc7f0080f1f056c4d145451608ebd3e807422a Author: Richard Biener Date: Wed Nov 25 12:31:54 2020 +0100 middle-end/97579 - lower VECTOR_BOOLEAN_TYPE_P VEC_COND_EXPRs This makes sure to lower VECTOR_BOOLEAN_TYPE_P typed non-vector mode VEC_COND_EXPRs so we don't try to use vcond to expand those. That's required for x86 and gcn integer mode boolean vectors. 2020-11-25 Richard Biener PR middle-end/97579 * gimple-isel.cc (gimple_expand_vec_cond_expr): Lower VECTOR_BOOLEAN_TYPE_P, non-vector mode VEC_COND_EXPRs. * gcc.dg/pr97579.c: New testcase.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #9 from Richard Biener ---
mask__258.181_254 = vect_cst__77 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 };
mask__581.199_1001 = VEC_COND_EXPR ;
so we're having a VEC_COND_EXPR with vector boolean type, sth we are not
prepared to handle (at least if it's not a classical vector mode one).
if (used_vec_cond_exprs >= 2
&& (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
!= CODE_FOR_nothing)
&& expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
{
/* Keep the SSA name and use vcond_mask. */
tcode = TREE_CODE (op0);
}
in the implicit else we assume vcond can handle this, but it will obviously
fail for a non-vector mode.
icode = get_vcond_icode (mode, cmp_op_mode, unsignedp);
where we have mode == HImode and cmp_op_mode V16SImode. I'm not sure aarch64
SVE or riscv will like VNBImode here.
Unless we want to disallow vector boolean typed VEC_COND_EXPRs alltogether
we have to lower them somewhere which probably is in ISEL. For the above
we'd produce
_75 = ~mask__258.181_254;
_897 = mask__649.185_117 & _75;
mask__581.199_1001 = _897;
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 --- Comment #8 from Richard Biener --- (In reply to Jakub Jelinek from comment #7) > Actually still ICEs. Yes, it was just a fix for the ISEL logic which was broken, not yet a fix for the actual testcase.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 --- Comment #7 from Jakub Jelinek --- Actually still ICEs.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- So fixed? Any reason why the testcase hasn't been added to the testsuite? I can test it on skylake-avx512 and add it there.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d0d8a1658054258baae87b445678c1c0c08d9455 commit r11-4674-gd0d8a1658054258baae87b445678c1c0c08d9455 Author: Richard Biener Date: Tue Nov 3 14:53:24 2020 +0100 middle-end/97579 - fix VEC_COND_EXPR ISEL optab query This fixes a mistake in the optab query done by ISEL. It doesn't fix the PR but shifts the ICE elsewhere. 2020-11-03 Richard Biener PR middle-end/97579 * gimple-isel.cc (gimple_expand_vec_cond_expr): Use the correct types for the vcond_mask/vec_cmp optab queries.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
--- Comment #4 from Martin Liška ---
>
> Hmm, but get_vcond_mask_icode expects the vector mode first and the
> mask mode second. But it would be odd if that's the mistake...
> (but the patterns agree as well).
>
> Now, the code seems to be a bit confused. We're looking at
>
>
> op0 = op0a tcode op0b;
> lhs = op0 ? op1 : op2;
>
> and I assume the check tries to verify we can expand both the
> compare-to-mask and the vcond_mask. Then we need to query
>
> tree op0_type = TREE_TYPE (op0);
> tree op0a_type = TREE_TYPE (op0a);
> if (used_vec_cond_exprs >= 2
> && (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
> != CODE_FOR_nothing)
> && expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> {
>
> no?
Yes, the code was really bogus. I understand it now as you and there's patch
for it:
diff --git a/gcc/gimple-isel.cc b/gcc/gimple-isel.cc
index b64e31fc6fe..bba41f84ef1 100644
--- a/gcc/gimple-isel.cc
+++ b/gcc/gimple-isel.cc
@@ -158,15 +158,22 @@ gimple_expand_vec_cond_expr (gimple_stmt_iterator *gsi,
gassign *def_stmt = dyn_cast (SSA_NAME_DEF_STMT (op0));
if (def_stmt)
{
+ /* We process the following statements:
+op0 = op0a tcode op0b;
+lhs = op0 ? op1 : op2;
+
+where MODE is mode of the LHS.
+ */
tcode = gimple_assign_rhs_code (def_stmt);
op0a = gimple_assign_rhs1 (def_stmt);
op0b = gimple_assign_rhs2 (def_stmt);
+ tree op0_type = TREE_TYPE (op0);
tree op0a_type = TREE_TYPE (op0a);
if (used_vec_cond_exprs >= 2
- && (get_vcond_mask_icode (mode, TYPE_MODE (op0a_type))
+ && (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
!= CODE_FOR_nothing)
- && expand_vec_cmp_expr_p (op0a_type, TREE_TYPE (lhs), tcode))
+ && expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
{
/* Keep the SSA name and use vcond_mask. */
tcode = TREE_CODE (op0);
> That would match
>
> if (TREE_CODE_CLASS (tcode) != tcc_comparison)
> {
> gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0)));
> if (get_vcond_mask_icode (mode, TYPE_MODE (TREE_TYPE (op0)))
> != CODE_FOR_nothing)
Yes, it's expanded as a .VCOND_MASK now.
>
> Doing that shifts the ICE elsewhere though:
>
> during GIMPLE pass: isel
> x.c: In function 'calc_rows':
> x.c:22:1: internal compiler error: in gimple_expand_vec_cond_expr, at
> gimple-isel.cc:204
>22 | calc_rows() {
> | ^
> 0x17c3bd8 gimple_expand_vec_cond_expr
> /home/rguenther/src/gcc2/gcc/gimple-isel.cc:202
>
> Now we face the situation where lhs == HImode but op0a is V16SImode
> so a VEC_COND_EXPR combining masks based on a compare. That's
> a situation we didn't run into before the VEC_COND_EXPR splitting.
I can confirm that:
mask__258.180_254 = vect_cst__77 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 };
mask__581.198_1001 = VEC_COND_EXPR ;
>
> Which means we're missing a fallback like
>
> if (expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
> {
> expand the comparison to a mask
> turn the VEC_COND_EXPR into a mask operation,
> maskr = cmpmask ? maska : maskb;
> becomes
> maskr = (maska & cmpmask) | (maskb & ~cmpmask);
> }
>
> the alternative is to add vcond_mask patterns for mask value modes
> (I think vternlog can do this in one operation, there may also be
> a mask operation for this). But that would be an enhancement
> and not require any new fallback code.
>
> But first double-check the first point I made above.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
--- Comment #3 from rguenther at suse dot de ---
On Tue, 27 Oct 2020, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
>
> --- Comment #2 from Martin Li?ka ---
> (In reply to Richard Biener from comment #1)
> > So we have used_vec_cond_exprs == 1 and a V16SI eq/ne compare with a
> > vector(16) HImode result. We fall into
> >
> > gcc_assert (known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE (cmp_op_mode))
> > && known_eq (GET_MODE_NUNITS (mode),
> >GET_MODE_NUNITS (cmp_op_mode)));
> >
> > then but this is clearly a case where we _have_ to use the vec_cmp_expr
> > (because of the scalar mode). So either simply remove the
> > used_vec_cond_exprs check or amend it with the negative of the above assert.
>
> No, used_vec_cond_exprs == 2, but we fail here:
>
>166if (used_vec_cond_exprs >= 2
>167&& (get_vcond_mask_icode (mode, TYPE_MODE (op0a_type))
>168!= CODE_FOR_nothing)
>169&& expand_vec_cmp_expr_p (op0a_type, TREE_TYPE (lhs),
> tcode))
>
> where:
>
> #0 get_vcond_mask_icode (vmode=E_HImode, mmode=E_V16SImode) at
> /home/marxin/Programming/gcc/gcc/optabs-query.h:131
>
> returns false.
Hmm, but get_vcond_mask_icode expects the vector mode first and the
mask mode second. But it would be odd if that's the mistake...
(but the patterns agree as well).
Now, the code seems to be a bit confused. We're looking at
op0 = op0a tcode op0b;
lhs = op0 ? op1 : op2;
and I assume the check tries to verify we can expand both the
compare-to-mask and the vcond_mask. Then we need to query
tree op0_type = TREE_TYPE (op0);
tree op0a_type = TREE_TYPE (op0a);
if (used_vec_cond_exprs >= 2
&& (get_vcond_mask_icode (mode, TYPE_MODE (op0_type))
!= CODE_FOR_nothing)
&& expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
{
no? That would match
if (TREE_CODE_CLASS (tcode) != tcc_comparison)
{
gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0)));
if (get_vcond_mask_icode (mode, TYPE_MODE (TREE_TYPE (op0)))
!= CODE_FOR_nothing)
Doing that shifts the ICE elsewhere though:
during GIMPLE pass: isel
x.c: In function 'calc_rows':
x.c:22:1: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:204
22 | calc_rows() {
| ^
0x17c3bd8 gimple_expand_vec_cond_expr
/home/rguenther/src/gcc2/gcc/gimple-isel.cc:202
Now we face the situation where lhs == HImode but op0a is V16SImode
so a VEC_COND_EXPR combining masks based on a compare. That's
a situation we didn't run into before the VEC_COND_EXPR splitting.
Which means we're missing a fallback like
if (expand_vec_cmp_expr_p (op0a_type, op0_type, tcode))
{
expand the comparison to a mask
turn the VEC_COND_EXPR into a mask operation,
maskr = cmpmask ? maska : maskb;
becomes
maskr = (maska & cmpmask) | (maskb & ~cmpmask);
}
the alternative is to add vcond_mask patterns for mask value modes
(I think vternlog can do this in one operation, there may also be
a mask operation for this). But that would be an enhancement
and not require any new fallback code.
But first double-check the first point I made above.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 --- Comment #2 from Martin Liška --- (In reply to Richard Biener from comment #1) > So we have used_vec_cond_exprs == 1 and a V16SI eq/ne compare with a > vector(16) HImode result. We fall into > > gcc_assert (known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE (cmp_op_mode)) > && known_eq (GET_MODE_NUNITS (mode), >GET_MODE_NUNITS (cmp_op_mode))); > > then but this is clearly a case where we _have_ to use the vec_cmp_expr > (because of the scalar mode). So either simply remove the > used_vec_cond_exprs check or amend it with the negative of the above assert. No, used_vec_cond_exprs == 2, but we fail here: 166if (used_vec_cond_exprs >= 2 167&& (get_vcond_mask_icode (mode, TYPE_MODE (op0a_type)) 168!= CODE_FOR_nothing) 169&& expand_vec_cmp_expr_p (op0a_type, TREE_TYPE (lhs), tcode)) where: #0 get_vcond_mask_icode (vmode=E_HImode, mmode=E_V16SImode) at /home/marxin/Programming/gcc/gcc/optabs-query.h:131 returns false.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target||x86_64-*-* i?86-*-* CC||marxin at gcc dot gnu.org --- Comment #1 from Richard Biener --- So we have used_vec_cond_exprs == 1 and a V16SI eq/ne compare with a vector(16) HImode result. We fall into gcc_assert (known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE (cmp_op_mode)) && known_eq (GET_MODE_NUNITS (mode), GET_MODE_NUNITS (cmp_op_mode))); then but this is clearly a case where we _have_ to use the vec_cmp_expr (because of the scalar mode). So either simply remove the used_vec_cond_exprs check or amend it with the negative of the above assert.
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||10.2.0 Target Milestone|--- |11.0 Last reconfirmed||2020-10-26 Ever confirmed|0 |1 Known to fail||11.0
