[Bug tree-optimization/97579] New: [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

[Bug tree-optimization/97579] New: [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

            Bug ID: 97579
           Summary: [11 Regression] ICE in gimple_expand_vec_cond_expr, at
                    gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

The issue was probably latent:

$ cat meteor.c
int bad_odd_rows_0_0, rows_bad_row1, rows_bad_group_okay, calc_rows_row2;

int
rows_bad() {
  int i, in_zeroes;
  char block;
  i = 0;
  for (; i < 5; i++)
    if (rows_bad_row1 & i)
      in_zeroes = 0;
    else {
      if (!in_zeroes)
        in_zeroes = 1;
      if (block & 1)
        rows_bad_group_okay = 1;
    }
  if (in_zeroes)
    return rows_bad_group_okay;
}

void
calc_rows() {
  for (; calc_rows_row2; calc_rows_row2++) {
    rows_bad();
    bad_odd_rows_0_0 = rows_bad();
  }
}

$ gcc meteor.c --param=max-unswitch-insns=1024 -O3 -mavx512vl -c
during GIMPLE pass: isel
meteor.c: In function ‘calc_rows’:
meteor.c:22:1: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:201
   22 | calc_rows() {
      | ^~~~~~~~~
0x72d8f5 gimple_expand_vec_cond_expr
        /home/marxin/Programming/gcc/gcc/gimple-isel.cc:201
0xff19d0 gimple_expand_vec_exprs
        /home/marxin/Programming/gcc/gcc/gimple-isel.cc:247
0xff19d0 execute
        /home/marxin/Programming/gcc/gcc/gimple-isel.cc:300
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

The problematic statement is:

(gdb) p debug_gimple_stmt(stmt)
mask__581.198_1001 = VEC_COND_EXPR <mask__258.180_254, { 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0 }, mask__649.184_117>;

(gdb) p mode
$3 = E_HImode
(gdb) p cmp_op_mode
$4 = E_V16SImode

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

Martin Liška <marxin at gcc dot gnu.org> 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

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Target|                            |x86_64-*-* i?86-*-*
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we have used_vec_cond_exprs == 1 and a V16SI eq/ne compare with a
vector(16) <signed-boolean:1> 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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
(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) <signed-boolean:1> 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:

   166            if (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

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

--- Comment #3 from rguenther at suse dot de <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 <marxin at gcc dot gnu.org> ---
> (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) <signed-boolean:1> 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:
> 
>    166            if (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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
> 
> 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<gassign *> (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 <mask__258.180_254, { 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0 }, mask__649.184_117>;

> 
> 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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:d0d8a1658054258baae87b445678c1c0c08d9455

commit r11-4674-gd0d8a1658054258baae87b445678c1c0c08d9455
Author: Richard Biener <rguenther@suse.de>
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  <rguenther@suse.de>

            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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
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 <mask__258.181_254, { 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0 }, mask__649.185_117>;

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:fddc7f0080f1f056c4d145451608ebd3e807422a

commit r11-5364-gfddc7f0080f1f056c4d145451608ebd3e807422a
Author: Richard Biener <rguenther@suse.de>
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  <rguenther@suse.de>

            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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asolokha at gmx dot com

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 97239 has been marked as a duplicate of this bug. ***