[Bug tree-optimization/114736] New: ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[Bug tree-optimization/114736] New: ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[prathamesh3492 at gcc dot gnu.org]

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

            Bug ID: 114736
           Summary: ICE during SLP pass with gfortran-13 -O3
                    -mcpu=neoverse-v2
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
For the following test-case:

SUBROUTINE MY_ROUTINE (N, A, B )
IMPLICIT NONE
INTEGER,   INTENT(IN)    :: N
COMPLEX,   INTENT(IN)    :: A(N)
COMPLEX,   INTENT(OUT)   :: B(N)
INTEGER                  :: II
B(:) = (1.,0.)
DO II = 1, N-1
    B(II) = A(N-II+1) / A(N-II)
ENDDO
END SUBROUTINE MY_ROUTINE

Compiling with gfortran-13 -O3 -mcpu=neoverse-v2 results in following ICE:

during GIMPLE pass: slp
dump file: t5.f90.180t.slp1
t5.f90:1:21:

    1 | SUBROUTINE MY_ROUTINE (N, A, B )
      |                     ^
internal compiler error: in create_partitions, at tree-vect-slp.cc:4226
0x12a4aef vect_optimize_slp_pass::create_partitions()
        ../../gcc/gcc/tree-vect-slp.cc:4226
0x12a617b vect_optimize_slp_pass::run()
        ../../gcc/gcc/tree-vect-slp.cc:5642
0x12a626b vect_optimize_slp(vec_info*)
        ../../gcc/gcc/tree-vect-slp.cc:5666
0x12abdef vect_optimize_slp(vec_info*)
        ../../gcc/gcc/tree-vect-slp.cc:7486
0x12abdef vect_slp_analyze_bb_1
        ../../gcc/gcc/tree-vect-slp.cc:7450
0x12abdef vect_slp_region
        ../../gcc/gcc/tree-vect-slp.cc:7538
0x12adc0b vect_slp_bbs
        ../../gcc/gcc/tree-vect-slp.cc:7746
0x12adf57 vect_slp_function(function*)
        ../../gcc/gcc/tree-vect-slp.cc:7847
0x12b949f execute
        ../../gcc/gcc/tree-vectorizer.cc:1529

Thanks,
Prathamesh

[Bug tree-optimization/114736] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Investigating this a bit further, the ICE appears with gfortran-13 because for
the testcase, because length of postorder traversal over SLP graph (27) doesn't
match number of nodes (28), and thus we hit the following assert in
create_partitions:

   /* Calculate a postorder of the graph, ignoring edges that correspond
     to natural latch edges in the cfg.  Reading the vector from the end
     to the beginning gives the reverse postorder.  */
  auto_vec<int> initial_rpo;
  graphds_dfs (m_slpg, &m_leafs[0], m_leafs.length (), &initial_rpo,
               false, NULL, skip_cfg_latch_edges);
  gcc_assert (initial_rpo.length () == m_vertices.length ());

Postorder traversal of graph (initial_rpo) shows:
vertices: [ 0 1 2 3 4 5 6 7 8 9 22 23 24 10 11 12 13 14 15 16 17
            18 19 20 21 25 27 ]
Vertex 26 seems to be missing, which corresponds to bb15, and thus
initial_rpo.length() is one less than m_vertices.length().

(If we don't ignore cfg latch edges during dfs walk, then it seems to "work",
but that's not right approach I guess...)

The issue doesn't reproduce with master, running git bisect showed it went away
after:
http://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=43da77a4f1636280c4259402c9c2c543e6ec6c0b

With 43da77a4, vect_slp_function splits the region at offending bb15, because
it is loop header, and it's containing loop gets marked as dont_vectorize by
ifcvt.
slp dump shows:
t5.f90:1:21: missed: splitting region at dont-vectorize loop 3 entry at bb15

So, bb15 doesn't get passed to vect_slp_bbs and eventually to
create_partitions,
avoiding the assert. So I am wondering if the issue has gone latent on trunk
rather than fixed since presence or absence of loop->dont_vectorize shouldn't
affect correctness of BB vectorizer ?

Perhaps not relevant, but this issue seems to surface only with -O3 -
mcpu=neoverse-v2. It doesn't surface with -O3, or -O3 -mcpu=generic+sve2 or
even trying out equivalent -march options corresponding to neoverse-v2:
-march=armv9-a+rng+crc+i8mm+bf16+sve2-bitperm+memtag+profile.

Thanks,
Prathamesh

[Bug tree-optimization/114736] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 57956
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57956&action=edit
Input to SLP pass (dse4 dump)

[Bug tree-optimization/114736] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does -fno-cost-model affect the behavior here?

[Bug tree-optimization/114736] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> Does -fno-cost-model affect the behavior here?

Sorry -fno-vect-cost-model.

[Bug tree-optimization/114736] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #3)
> Does -fno-cost-model affect the behavior here?

With 43da77a4, it doesn't result in ICE with -fno-vect-cost-model or
-fvect-cost-model=unlimited.

Prior to 43da77a4, it still results in ICE with -fno-vect-cost-model. It only
seems to pass with -fvect-cost-model=very-cheap.

Thanks,
Prathamesh

[Bug tree-optimization/114736] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 57957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57957&action=edit
SLP dump

[Bug tree-optimization/114736] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's probably latent on trunk.  The assert verifies all vertices are backward
reachable from the leafs.  vertices and leafs are discovered with a DFS
from the instances.

So the question is what's that missing vertex and why is it not backward
reachable.

[Bug tree-optimization/114736] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2024-04-16
     Ever confirmed|0                           |1

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  The missing node is

t.f90:1:21: note: node 0x39e3a80 (max_nunits=1, refcnt=2) vector(2)
real(kind=4)
t.f90:1:21: note: op: VEC_PERM_EXPR
t.f90:1:21: note:       { }
t.f90:1:21: note:       lane permutation { 0[1] 0[0] }
t.f90:1:21: note:       children 0x39e37b0

23 (4)  <- 22
        -> 26 24

26 (-1) <- 23
        -> 17

17 (6)  <- 26 16
        -> 19 18

and the edge making it backward reachable is marked as latch.  Specifically
those vertices we mark as leaf forcefully in build_vertices do not match
those made unreachable by build_graph via ignoring latch edges.

t.f90:1:21: note: node 0x39e37b0 (max_nunits=2, refcnt=2) vector(2)
real(kind=4)
t.f90:1:21: note: op template: a__I_IM_lsm0.22_6 = PHI <_12(20), _73(19)>
t.f90:1:21: note:       stmt 0 a__I_IM_lsm0.22_6 = PHI <_12(20), _73(19)>
t.f90:1:21: note:       stmt 1 a__I_RE_lsm0.23_18 = PHI <_11(20), _74(19)>
t.f90:1:21: note:       children 0x39e3840 0x39e38d0

and the issue is that the representative of the VEC_PERM node is
a__I_IM_lsm0.22_6 = PHI <_12(20), _73(19)> (a NULL one is avoided for crashes).

[Bug tree-optimization/114736] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from GCC 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:f949481a1f7ab973608a4ffcc0e342ab5a74e8e4

commit r14-9993-gf949481a1f7ab973608a4ffcc0e342ab5a74e8e4
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Apr 16 11:33:48 2024 +0200

    tree-optimization/114736 - SLP DFS walk issue

    The following fixes a DFS walk issue when identifying to be ignored
    latch edges.  We have (bogus) SLP_TREE_REPRESENTATIVEs for VEC_PERM
    nodes so those have to be explicitly ignored as possibly being PHIs.

            PR tree-optimization/114736
            * tree-vect-slp.cc (vect_optimize_slp_pass::is_cfg_latch_edge):
            Do not consider VEC_PERM_EXPRs as PHI use.

            * gfortran.dg/vect/pr114736.f90: New testcase.

[Bug tree-optimization/114736] [13 Regression] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.3
      Known to work|                            |14.0
      Known to fail|                            |13.2.1
            Summary|ICE during SLP pass with    |[13 Regression] ICE during
                   |gfortran-13 -O3             |SLP pass with gfortran-13
                   |-mcpu=neoverse-v2           |-O3 -mcpu=neoverse-v2

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Not sure if older releases are also affected.

[Bug tree-optimization/114736] [13 Regression] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #11 from prathamesh3492 at gcc dot gnu.org ---
Hi Richard,
Thanks for the quick fix! I verified it now compiles the test-case with -O3
-mcpu=neoverse-v2. I suppose this will need backporting to gcc-13 branch. The
test compiles OK with gfortran-12.

Thanks,
Prathamesh

[Bug tree-optimization/114736] [13 Regression] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:0624852a3ea684f6b9dabea864bcb45e31304728

commit r13-8683-g0624852a3ea684f6b9dabea864bcb45e31304728
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Apr 16 11:33:48 2024 +0200

    tree-optimization/114736 - SLP DFS walk issue

    The following fixes a DFS walk issue when identifying to be ignored
    latch edges.  We have (bogus) SLP_TREE_REPRESENTATIVEs for VEC_PERM
    nodes so those have to be explicitly ignored as possibly being PHIs.

            PR tree-optimization/114736
            * tree-vect-slp.cc (vect_optimize_slp_pass::is_cfg_latch_edge):
            Do not consider VEC_PERM_EXPRs as PHI use.

            * gfortran.dg/vect/pr114736.f90: New testcase.

    (cherry picked from commit f949481a1f7ab973608a4ffcc0e342ab5a74e8e4)

[Bug tree-optimization/114736] [13 Regression] ICE during SLP pass with gfortran-13 -O3 -mcpu=neoverse-v2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|13.2.1                      |13.2.0
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
      Known to work|                            |13.2.1
           Priority|P3                          |P2

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