[Bug target/104112] New: ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512

[Bug target/104112] New: ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512

[gilles.gouaillardet at gmail dot com]

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

            Bug ID: 104112
           Summary: ICE with -Ofast -march=armv8.2-a+sve
                    -msve-vector-bits=512
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 52226
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52226&action=edit
a simple reproducer

The attached reproducer (trimmed from BLAS) can be used to evidence a crash of
the compiler:

$ g++ -march=armv8.2-a+sve -msve-vector-bits=512 -Ofast -c boom.cpp 
during GIMPLE pass: vect
boom.cpp: In function ?void boom(int, double*, double*)?:
boom.cpp:4:1: internal compiler error: Segmentation fault
    4 | boom(int n,
      | ^~~~
0x10436f3 crash_signal
        ../.././gcc/toplev.c:328
0x12f86ec tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
        ../.././gcc/tree.h:3495
0x12f86ec vect_create_partial_epilog
        ../.././gcc/tree-vect-loop.c:4953
0x13050ff vect_transform_cycle_phi(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, _slp_instance*)
        ../.././gcc/tree-vect-loop.c:7728
0x12f562b vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
        ../.././gcc/tree-vect-stmts.c:10999
0x1311e9b vect_transform_loop(_loop_vec_info*, gimple*)
        ../.././gcc/tree-vect-loop.c:9686
0x13416db try_vectorize_loop_1
        ../.././gcc/tree-vectorizer.c:1103
0x13418b7 try_vectorize_loop_1
        ../.././gcc/tree-vectorizer.c:1141
0x1342317 vectorize_loops()
        ../.././gcc/tree-vectorizer.c:1242
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.


FWIW, g++ works just fine with the slightly rewritten (e.g. do not use a local
variable) noboom.cpp

Based on my snapshots, the issue occurred first between 20210711 and 20210718
(I am now running a git bisect to point to a suspect commit)

[Bug target/104112] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512

[gilles.gouaillardet at gmail dot com]

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

--- Comment #1 from Gilles Gouaillardet <gilles.gouaillardet at gmail dot com> ---
Created attachment 52227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52227&action=edit
a slightly rewritten reproducer that passes compilation

[Bug target/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
            Summary|ICE with -Ofast             |[12 Regression] ICE with
                   |-march=armv8.2-a+sve        |-Ofast -march=armv8.2-a+sve
                   |-msve-vector-bits=512       |-msve-vector-bits=512 since
                   |                            |r12-2292-g1dd3f21095858fbfd
                   |                            |3e28a149578d5fb67e75f95
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Target Milestone|---                         |12.0
   Last reconfirmed|                            |2022-01-19

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95.

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look.

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the issue is we hit

vect_create_partial_epilog (tree vec_def, tree vectype, code_helper code,
                            gimple_seq *seq)
{
  unsigned nunits = TYPE_VECTOR_SUBPARTS (TREE_TYPE (vec_def)).to_constant ();
  unsigned nunits1 = TYPE_VECTOR_SUBPARTS (vectype).to_constant ();
  tree stype = TREE_TYPE (vectype);
  tree new_temp = vec_def;
  while (nunits > nunits1)
    {
      nunits /= 2;
      tree vectype1 = get_related_vectype_for_scalar_type (TYPE_MODE (vectype),
                                                           stype, nunits);
      unsigned int bitsize = tree_to_uhwi (TYPE_SIZE (vectype1));

with

(gdb) p debug_generic_expr (vectype)
vector(2) double
$3 = void
(gdb) p debug_generic_expr (vec_def->typed.type)
vector(8) double

but when looking for a nunits == 4 vectype we end up with no valid vector type.
returned from get_related_vectype_for_scalar_type.

The code that checks whether we can vectorize doesn't verify that such
modes exist, that would need to be added.  But maybe the above isn't
exactly the correct way to get at it?  Do the command-line options
really disable V4DFmode support?

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Oh, the V8DFmode is actually VNx2DF but I guess the constant size will fool us
to think it's not a variable size mode.

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
The following adds such verification

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 0fe3529b2d1..6ce33f3cef0 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -4979,9 +4979,20 @@ vect_find_reusable_accumulator (loop_vec_info
loop_vinfo,
   /* Handle the case where we can reduce wider vectors to narrower ones.  */
   tree vectype = STMT_VINFO_VECTYPE (reduc_info);
   tree old_vectype = TREE_TYPE (accumulator->reduc_input);
+  unsigned HOST_WIDE_INT m;
   if (!constant_multiple_p (TYPE_VECTOR_SUBPARTS (old_vectype),
-                           TYPE_VECTOR_SUBPARTS (vectype)))
+                           TYPE_VECTOR_SUBPARTS (vectype), &m))
     return false;
+  /* Check the intermediate vector types are available.  */
+  while (m > 2)
+    {
+      m /= 2;
+      tree intermediate_vectype = get_related_vectype_for_scalar_type
+       (TYPE_MODE (vectype), TREE_TYPE (vectype),
+        exact_div (TYPE_VECTOR_SUBPARTS (old_vectype), m));
+      if (!intermediate_vectype)
+       return false;
+    }

   /* Non-SLP reductions might apply an adjustment after the reduction
      operation, in order to simplify the initialization of the accumulator.

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 52230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52230&action=edit
patch I am testing

I'm testing this patch on x86_64-linux, aarch64 testing appreciated.

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Oh, and we're also not verifying

      /* The target has to make sure we support lowpart/highpart
         extraction, either via direct vector extract or through
         an integer mode punning.  */

and an alternative would be to do the reduction in the wider mode
and only do a final lowpart extraction, but that would require
the support of some intermediate const permutes so we get

  { 0, 1, 2, 3, 4, 5, 6, 7 }
+ { 4, 5, 6, 7, /* dont-care */ }
+ { 2+6, 3+7, /* dont-care */ }

basically whole-vector shifts by half and a quater of the vector
for one missing intermediate mode and then the appropriate lowpart
of the final vector mode.

code-gen wise with the proposed patch we get no accumulator re-use
while with the above scheme we might be able to re-use it (not sure
if SVE is capable of that or whether that would be profitable).

Without -msve-vector-bits=512 we simply get variable length vector code.
There doesn't seem to be -msve-vector-bits=512,256 or so to enable
both lengths (the compiler could set a static mask to "emulate" 256
with fixed 512 vectors?)

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Thanks for the patch.  I'm currently testing it on SVE.

(In reply to Richard Biener from comment #8)


> Without -msve-vector-bits=512 we simply get variable length vector code.
> There doesn't seem to be -msve-vector-bits=512,256 or so to enable
> both lengths (the compiler could set a static mask to "emulate" 256
> with fixed 512 vectors?)
For SVE there's nothing really special about half a vector, so there
should be no reason to need successive halving (e.g. 512-bit main
loop, 256-bit epilogue, 128-bit epilogue, once we support multiple
epilogues).  If predicating for 256 bits works then predicating
for however many scalar bits are left should work too.  The same
goes for reductions.

I haven't had chance to look at the testcase yet, but it sounds like
it's one of those cases (such as reversed accesses) where we still
don't support predicating the loop.  If so, I think the optimisation
focus would be on removing that restriction instead.

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
On i?86 we could eventually hit the same issue with

unsigned short foo (unsigned short *a, int n)
{
  unsigned short sum = 0;
  for (int i = 0; i < n; ++i)
    sum += a[i];
  return sum;
}

since V8HI is available with SSE2 but V4HI is limited (no add) because of
the fear of MMX but then we make V2HI available again but epilogue
vectorization with V2HI isn't considered profitable.  Disabling the
cost model produces V4HI ops even though the mode was not advertised
(or we failed to iterate over that mode for some reason).  The V4HI
adds are also code generated by the vectorizer but later decomposed
by vector lowering so the generated code is a bit awful.

That said, i?86 does have V4HImode support but not V4HImode adds
(V4HI would also match word_mode, not sure if we'd ever select that
via get_related_vectype_for_scalar_type).

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52230|0                           |1
        is obsolete|                            |

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 52232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52232&action=edit
adjusted patch

This also tests for availability of the reduction operation in the intermediate
mode which avoids V4HI vector adds on !TARGET_MMX_WITH_SSE as those are later
decomposed by vector lowering.

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 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:5b6788ae5a365aecd6776f563e44022acb93a57a

commit r12-6737-g5b6788ae5a365aecd6776f563e44022acb93a57a
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Jan 19 12:31:30 2022 +0100

    tree-optimization/104112 - add check for vect epilogue reduc reuse

    This adds a missing check for the availability of intermediate vector
    types required to re-use the accumulator of a vectorized reduction
    in the vectorized epilogue.  For SVE and VNx2DF vs V2DF with
    -msve-vector-bits=512 for example V4DF is not available.

    In addition to that we have to verify the reduction operation is
    supported, otherwise we for example on i?86 get vector code that's
    later decomposed again by vector lowering when trying to use
    a V2HI epilogue for a V8HI reduction with a target without
    TARGET_MMX_WITH_SSE.

    It might be we want -Wvector-operation-performance for all vect.exp
    tests but that seems to have existing regressions.

    2022-01-19  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/104112
            * tree-vect-loop.cc (vect_find_reusable_accumulator): Check
            for required intermediate vector types.

            * gcc.dg/vect/pr104112-1.c: New testcase.
            * gcc.dg/vect/pr104112-2.c: New testcase.

[Bug tree-optimization/104112] [12 Regression] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512 since r12-2292-g1dd3f21095858fbfd3e28a149578d5fb67e75f95

[rguenth at gcc dot gnu.org]

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

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

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

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