[Bug tree-optimization/106063] New: [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[Bug tree-optimization/106063] New: [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[zsojka at seznam dot cz]

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

            Bug ID: 106063
           Summary: [13 Regression] ICE: in gimple_expand_vec_cond_expr,
                    at gimple-isel.cc:281 with -O2 -fno-tree-forwprop
                    --param=evrp-mode=legacy-first
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu

Created attachment 53194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53194&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first
testcase.c
during GIMPLE pass: isel
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:281
    4 | foo (V v)
      | ^~~
0x7fc007 gimple_expand_vec_cond_expr
        /repo/gcc-trunk/gcc/gimple-isel.cc:281
0x7fc007 gimple_expand_vec_exprs
        /repo/gcc-trunk/gcc/gimple-isel.cc:311
0x7fc007 execute
        /repo/gcc-trunk/gcc/gimple-isel.cc:365
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1213-20220623060722-g31ce821a790-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1213-20220623060722-g31ce821a790-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220623 (experimental) (GCC)

[Bug tree-optimization/106063] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #1 from Andrew Macleod <amacleod at redhat dot com> ---
That option enables legacy EVRP, and will be going away soon.  however, looking
at the IL, the difference out of EVRP is that legacy doesnt touch the code. The
IL is:

  vector(1) __int128 _1;
  vector(1) <signed-boolean:128> _2;
  V _4;

  <bb 2> :
  _1 = v_3(D) & { 15 };
  _2 = v_3(D) == _1;
  _4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>;
  return _4;


Ranger ends up triggering a simplification :

Folding statement: _2 = v_3(D) == _1;
gimple_simplified to _6 = v_3(D) & { -16 };
_2 = _6 == { 0 };
Folded into: _2 = _6 == { 0 };

producing:

    _1 = v_3(D) & { 15 };
    _6 = v_3(D) & { -16 };
    _2 = _6 == { 0 };
    _4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>;
    return _4;

Which ends up not causing the ICE seen in this PR.

However, if we completely disable EVRP, we also get the trap.

   -O2 -fno-tree-forwprop --disable-tree-evrp

So it would seem the problem probably lies with vector expansion?

[Bug tree-optimization/106063] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |tnfchris at gcc dot gnu.org
   Last reconfirmed|                            |2022-06-24

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Interestingly

typedef __int128 __attribute__((__vector_size__ (16))) V;
typedef unsigned __int128 __attribute__((__vector_size__ (16))) uV;
typedef V bV __attribute__((vector_mask));
V __GIMPLE (ssa,startwith("isel"))
foo (V v)
{
  uV _1;
  bV _2;
  V _4;

  __BB(2,guessed_local(1073741824)):
  _1 = __VIEW_CONVERT <uV>(v_3(D));
  _2 = _1 <= _Literal (uV) { _Literal (unsigned __int128) 15 };
  _4 = _2 ? _Literal (V) { _Literal (__int128) -1 } : _Literal (V) { 0 };
  return _4;

}

works, even with -fdisable-tree-veclower21

The issue is that we cannot expand the unsigned comparsion _2 = _1 <= { 15 };
which is introduced in VRP2 from the equality compare:

--- t2.c.197t.threadfull2       2022-06-24 12:25:08.204648605 +0200
+++ t2.c.198t.vrp2      2022-06-24 12:25:08.204648605 +0200
@@ -10,13 +10,15 @@
 ;; 2 succs { 1 }
 V foo (V v)
 {
+  vector(1) uint128_t _1;
   vector(1) <signed-boolean:128> _2;
   V _4;
   vector(1) __int128 _6;

   <bb 2> [local count: 1073741824]:
   _6 = v_3(D) & { -16 };
-  _2 = _6 == { 0 };
+  _1 = VIEW_CONVERT_EXPR<vector(1) uint128_t>(v_3(D));
+  _2 = _1 <= { 15 };
   _4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>;
   return _4;

but after vector lowering only vector operations that are handled by the
target may be introduced.  The pattern

/* Transform comparisons of the form (X & Y) CMP 0 to X CMP2 Z
   where ~Y + 1 == pow2 and Z = ~Y.  */
(for cst (VECTOR_CST INTEGER_CST)
 (for cmp (eq ne)
      icmp (le gt)
  (simplify
   (cmp (bit_and:c@2 @0 cst@1) integer_zerop)
    (with { tree csts = bitmask_inv_cst_vector_p (@1); }
     (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)))
      (if (TYPE_UNSIGNED (TREE_TYPE (@1)))
       (icmp @0 { csts; })
       (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); }
         (icmp (view_convert:utype @0) { csts; }))))))))

fails to check that in the vector case.  Caused by r12-5650-g29df53fe349073
(thus latent on the branch).

[Bug tree-optimization/106063] [12/13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.2
           Priority|P3                          |P2
            Summary|[13 Regression] ICE: in     |[12/13 Regression] ICE: in
                   |gimple_expand_vec_cond_expr |gimple_expand_vec_cond_expr
                   |, at gimple-isel.cc:281     |, at gimple-isel.cc:281
                   |with -O2 -fno-tree-forwprop |with -O2 -fno-tree-forwprop
                   |--param=evrp-mode=legacy-fi |--param=evrp-mode=legacy-fi
                   |rst                         |rst

[Bug tree-optimization/106063] [12/13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[tnfchris at gcc dot gnu.org]

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

--- Comment #3 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> 
> but after vector lowering only vector operations that are handled by the
> target may be introduced.  The pattern
> 

We can't tell that we're after veclower can we? so does it make sense to just
never introduce a vector operation the target has no optab for?

[Bug tree-optimization/106063] [12/13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Ah, there's optimize_vectors_before_lowering_p,

would you prefer I check the operation or just gate the pattern on the above
Richi?

[Bug tree-optimization/106063] [12/13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r13-1573-gf7854e2faf7640230062dec3596e71773ca500ed
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Fri Jul 8 08:30:22 2022 +0100

    middle-end: don't lower past veclower [PR106063]

    Hi All,

    My previous patch can cause a problem if the pattern matches after veclower
    as it may replace the construct with a vector sequence which the target may
not
    directly support.

    As such don't perform the rewriting if after veclower unless the target
supports
    the operation.  If before veclower do the rewriting as well if the target
didn't
    support the original operation either.

    gcc/ChangeLog:

            PR tree-optimization/106063
            * match.pd: Do not apply pattern after veclower is not supported.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/106063
            * gcc.dg/pr106063.c: New test.

[Bug tree-optimization/106063] [12 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Dimitar Dimitrov <dimitar@gcc.gnu.org>:

https://gcc.gnu.org/g:4ebbf3906895bcb40d7ff2729cf46deae66bc268

commit r13-1595-g4ebbf3906895bcb40d7ff2729cf46deae66bc268
Author: Dimitar Dimitrov <dimitar@dinux.eu>
Date:   Sun Jul 10 11:15:39 2022 +0300

    testsuite: Require int128 for gcc.dg/pr106063.c

    Require effective target int128 for gcc.dg/pr106063.c.

            PR tree-optimization/106063

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr106063.c: Require effective target int128.

    Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

[Bug tree-optimization/106063] [12 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:13d23c313374e15186f33fa6d57a0c9fd5d8b486

commit r12-8625-g13d23c313374e15186f33fa6d57a0c9fd5d8b486
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Fri Jul 8 08:30:22 2022 +0100

    middle-end: don't lower past veclower [PR106063]

    Hi All,

    My previous patch can cause a problem if the pattern matches after veclower
    as it may replace the construct with a vector sequence which the target may
not
    directly support.

    As such don't perform the rewriting if after veclower unless the target
supports
    the operation.  If before veclower do the rewriting as well if the target
didn't
    support the original operation either.

    gcc/ChangeLog:

            PR tree-optimization/106063
            * match.pd: Do not apply pattern after veclower is not supported.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/106063
            * gcc.dg/pr106063.c: New test.

    (cherry picked from commit f7854e2faf7640230062dec3596e71773ca500ed)

[Bug tree-optimization/106063] [12 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:019a9ef7f7466c0f41bdc8c5838f4f4926c938aa

commit r12-8626-g019a9ef7f7466c0f41bdc8c5838f4f4926c938aa
Author: Dimitar Dimitrov <dimitar@dinux.eu>
Date:   Sun Jul 10 11:15:39 2022 +0300

    testsuite: Require int128 for gcc.dg/pr106063.c

    Require effective target int128 for gcc.dg/pr106063.c.

            PR tree-optimization/106063

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr106063.c: Require effective target int128.

    Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
    (cherry picked from commit 4ebbf3906895bcb40d7ff2729cf46deae66bc268)

[Bug tree-optimization/106063] [12 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
      Known to work|                            |13.0
      Known to fail|13.0                        |12.1.0

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