[Bug tree-optimization/106433] New: [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

[Bug tree-optimization/106433] New: [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

[asolokha at gmx dot com]

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

            Bug ID: 106433
           Summary: [13 Regression] ICE in vect_transform_loops, at
                    tree-vectorizer.cc:1032
           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: asolokha at gmx dot com
  Target Milestone: ---
            Target: aarch64-linux-gnu

gcc 13.0.0 20220724 snapshot (g:8b8103dcd2624936bd1f56ac2ee63d1fb779a7e4) ICEs
when compiling the following testcase w/ -march=armv8-a+sve -O1:

int n;

int
quux ()
{
  return n;
}

__attribute__ ((simd)) int
bar (int x)
{
  if (quux () != quux (0))
    n = 0;

  return quux ();
}

__attribute__ ((simd)) int
foo (void)
{
  return bar (0);
}

% aarch64-linux-gnu-gcc-13.0.0 -march=armv8-a+sve -O1 -c x83c1h7f.c
during GIMPLE pass: vect
x83c1h7f.c: In function 'foo.simdclone.0':
x83c1h7f.c:19:1: internal compiler error: in vect_transform_loops, at
tree-vectorizer.cc:1032
   19 | foo (void)
      | ^~~
0x7d0332 vect_transform_loops
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220724/work/gcc-13-20220724/gcc/tree-vectorizer.cc:1032
0x11f9f73 try_vectorize_loop_1
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220724/work/gcc-13-20220724/gcc/tree-vectorizer.cc:1153
0x11f9f73 try_vectorize_loop
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220724/work/gcc-13-20220724/gcc/tree-vectorizer.cc:1183
0x11fa534 execute
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220724/work/gcc-13-20220724/gcc/tree-vectorizer.cc:1299

[Bug tree-optimization/106433] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2022-07-25
           Keywords|                            |openmp
   Target Milestone|---                         |13.0
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  It looks like bar.simdclone.0 () is not pure but bar () was pure,
so sth is amiss in the simd cloning pass here?  We have

vector(2) int foo.simdclone.0 ()
{
...
  # VUSE <.MEM_7>
  _1 = bar (0);

but at IPA we don't yet know bar() is pure (its IL writes to memory).  Likely
late local pure/cost discovery fixes that up and affects foo.simdclone.0 but
the simdclone decl for bar() is created earlier (but not adjusted?).  Should
local-pure-const also affect aliases/clones (are the simdclone clones even
visible properly to do this?).

I guess simply adjusting the simdclone decl from the vectorizer when detecting
the mismatch in virtual operands is too ugly.

vector(2) int foo.simdclone.0 ()
{
...
  # .MEM = VDEF <.MEM_7>
  vect__1.39_12 = bar.simdclone.0 (vect_cst__11);

[Bug tree-optimization/106433] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug tree-optimization/106433] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha <asolokha at gmx dot com> ---
JFTR, I believe I can reproduce the same issue on x86_64 w/ the current gcc
13.0.0 20221023 (g:0e37fd4dc74c1db99cdc7d71ef378e1221253c6f) snapshot:

int m;
int *p;

__attribute__ ((simd)) int
bar (int x)
{
  if (x)
    {
      if (m < 1)
        for (m = 0; m < 1; ++m)
          ++x;

      p = &x;

      for (;;)
        ++m;
    }

  return 0;
}

__attribute__ ((simd)) int
foo (int x)
{
  return bar (x);
}

% x86_64-unknown-linux-gnu-gcc-13 -O2 -c rf5yfvga.c
during GIMPLE pass: vect
rf5yfvga.c: In function 'foo.simdclone.0':
rf5yfvga.c:23:1: internal compiler error: in vect_transform_loops, at
tree-vectorizer.cc:1032
   23 | foo (int x)
      | ^~~
0x7ac573 vect_transform_loops
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-vectorizer.cc:1032
0x11dd81f try_vectorize_loop_1
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-vectorizer.cc:1153
0x11dd81f try_vectorize_loop
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-vectorizer.cc:1183
0x11ddbd4 execute
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-vectorizer.cc:1299

[Bug tree-optimization/106433] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Interestingly the cgraph node for 'bar' doesn't have any clones when it changes
pure/const state so we cannot update those as well. 
create_version_clone_with_body as used by OMP cloning doesn't populate
those links it seems, as opposed to create_clone.

Honza?

[Bug tree-optimization/106433] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54413
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54413&action=edit
gcc13-pr106433.patch

Seems in this case the set_const_call happens far later, during the
local-pure-const2 pass very soon before expansion into RTL.
The simd clones are created during late IPA, but the cgraph ordering in this
case is that bar is optimized + expanded first, then its caller foo, then the
simd clones of foo and finally the simd clones of bar.  In order to be able to
DCE unneeded simd clones, that is the intended ordering that we process simd
clones only after processing their (possible) callers, so that if we decide not
to use them and they are static, they can go away.

The big question is if it is safe to make those clones const or pure if the
function they are cloned from is.  I'd hope it is, they are created by the
compiler from the functions they were cloned from and they should be just
possibly vectorized versions thereof handling more than one argument
concurrently.  I can imagine we'd be able to determine during optimizations one
is const and couldn't prove it for the other, but I'd say if it is safe for one
version it ought to be safe for another one too.

[Bug tree-optimization/106433] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r13-5727-gcad2412cc84518195fceb2db31e82e6df7e5a2c2
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 7 10:33:54 2023 +0100

    cgraph: Handle simd clones in cgraph_node::set_{const,pure}_flag [PR106433]

    The following testcase ICEs, because we determine only in late pure const
    pass that bar is const (the content of the function loses a store to a
    global var during dse3 and read from it during cddce2) and
local-pure-const2
    makes it const.  The cgraph ordering is that post IPA (in late IPA simd
    clones are created) bar is processed first, then foo as its caller, then
    foo.simdclone* and finally bar.simdclone*.  Conceptually I think that is
the
    right ordering which allows for static simd clones to be removed.

    The reason for the ICE is that because bar was marked const, the call to
    it lost vops before vectorization, and when we in foo.simdclone* try to
    vectorize the call to bar, we replace it with bar.simdclone* which hasn't
    been marked const and so needs vops, which we don't add.

    Now, because the simd clones are created from the same IL, just in a loop
    with different argument/return value passing, I think generally if the base
    function is determined to be const or pure, the simd clones should be too,
    unless e.g. the vectorization causes different optimization decisions, but
    then still the global memory reads if any shouldn't affect what the
function
    does and global memory stores shouldn't be reachable at runtime.

    So, the following patch changes set_{const,pure}_flag to mark also simd
    clones.

    2023-02-07  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/106433
            * cgraph.cc (set_const_flag_1): Recurse on simd clones too.
            (cgraph_node::set_pure_flag): Call set_pure_flag_1 on simd clones
too.

            * gcc.c-torture/compile/pr106433.c: New test.

[Bug tree-optimization/106433] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.