[Bug tree-optimization/95961] New: ICE: in exact_div, at poly-int.h:2182

[Bug tree-optimization/95961] New: ICE: in exact_div, at poly-int.h:2182

[felix.yang at huawei dot com]

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

            Bug ID: 95961
           Summary: ICE: in exact_div, at poly-int.h:2182
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: felix.yang at huawei dot com
  Target Milestone: ---
            Target: aarch64

test case:
$ cat foo.c
typedef struct {
    unsigned short mprr_2[5][16][16];
} ImageParameters;

int s[16][2];

void intrapred_luma_16x16(ImageParameters *img, int s0)
{
  for (int j = 0; j < 16; j++)
    for (int i = 0; i < 16; i++)
      {
        img->mprr_2[1][j][i] = s[j][1];
        img->mprr_2[2][j][i] = s0;
      }
}

Command line to reproduce:
$ gcc -O3 -march=armv8.2-a+sve -fno-vect-cost-model foo.c

Call trace:
during GIMPLE pass: vect
dump file: a-foo.c.163t.vect
foo.c: In function ‘intrapred_luma_16x16’:
foo.c:7:6: internal compiler error: in exact_div, at poly-int.h:2182
    7 | void intrapred_luma_16x16(ImageParameters *img, int s0)
      |      ^~~~~~~~~~~~~~~~~~~~
v0xdb6937 poly_int<2u, poly_result<unsigned long, unsigned long,
poly_coeff_pair_traits<unsigned long, unsigned long>::result_kind>::type>
exact_div<2u, unsigned long, unsigned long>(poly_int_pod<2u, unsigned long>
const&, poly_int_pod<2u, unsigned long> const&)
        ../../gcc-git/gcc/poly-int.h:2182
0x22934ef vect_get_num_vectors
        ../../gcc-git/gcc/tree-vectorizer.h:1647
0x2297d5f vect_enhance_data_refs_alignment(_loop_vec_info*)
        ../../gcc-git/gcc/tree-vect-data-refs.c:1827
0x1686adf vect_analyze_loop_2
        ../../gcc-git/gcc/tree-vect-loop.c:2138
0x1688267 vect_analyze_loop(loop*, vec_info_shared*)
        ../../gcc-git/gcc/tree-vect-loop.c:2612
0x16c77e7 try_vectorize_loop_1
        ../../gcc-git/gcc/tree-vectorizer.c:955
0x16c7f6f try_vectorize_loop
        ../../gcc-git/gcc/tree-vectorizer.c:1110
0x16c811f vectorize_loops()
        ../../gcc-git/gcc/tree-vectorizer.c:1189
0x151e6df execute
        ../../gcc-git/gcc/tree-ssa-loop.c:414

In vect_enhance_data_refs_alignment, when we call vect_get_num_vectors, we
have:
(gdb) p nscalars
$11 = {<poly_int_pod<2, unsigned long>> = {coeffs = {2, 2}}, <No data fields>}

(gdb) p debug_tree(vectype)
 <vector_type 0xffffb202f2a0
    type <integer_type 0xffffb22305e8 int sizes-gimplified public SI
        size <integer_cst 0xffffb221ffd8 constant 32>
        unit-size <integer_cst 0xffffb2234000 constant 4>
        align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0xffffb22305e8 precision:32 min <integer_cst 0xffffb221ff90 -2147483648> max
<integer_cst 0xffffb221ffa8 2147483647>
        pointer_to_this <pointer_type 0xffffb2238a80>>
    VNx4SI
......

(gdb) p TYPE_VECTOR_SUBPARTS (vectype)
$13 = {<poly_int_pod<2, unsigned long>> = {coeffs = {4, 4}}, <No data fields>}

nscalars is not a multiple of number of elements of vectype, which triggers the
ICE.

In the vect pass, vectorization factor computed by
vect_determine_vectorization_factor is [8,8]. But this is updated to [1, 1]
later by vect_update_vf_for_slp, as indicated in the phase dump:
7860 foo.c:9:3: note:   === vect_make_slp_decision ===
7861 foo.c:9:3: note:   Decided to SLP 2 instances. Unrolling factor [1,1]
7862 foo.c:9:3: note:   === vect_detect_hybrid_slp ===
7863 foo.c:9:3: note:   === vect_update_vf_for_slp ===
7864 foo.c:9:3: note:   Loop contains only SLP stmts
7865 foo.c:9:3: note:   Updating vectorization factor to [1,1].
7866 foo.c:9:3: note:  vectorization_factor = [1,1], niters = 16

This logic here was once changed by commit
d9f21f6acb3aa615834e855e16b6311cd18c5668:

 323                if (unlimited_cost_model (LOOP_VINFO_LOOP (loop_vinfo)))
 324                 {
 325 -                 if (STMT_SLP_TYPE (stmt_info))
 326 -                   possible_npeel_number
 327 -                     = (vf * GROUP_SIZE (stmt_info)) / nelements;
 328 -                 else
 329 -                   possible_npeel_number = vf / nelements;
 330 +                 poly_uint64 nscalars = (STMT_SLP_TYPE (stmt_info)
 331 +                                         ? vf * GROUP_SIZE (stmt_info) :
vf);
 332 +                 possible_npeel_number
 333 +                   = vect_get_num_vectors (nscalars, vectype);

Proposed fix:
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index eb8288e7a85..b30a7d8a3bb 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -1823,8 +1823,11 @@ vect_enhance_data_refs_alignment (loop_vec_info
loop_vinfo)
                {
                  poly_uint64 nscalars = (STMT_SLP_TYPE (stmt_info)
                                          ? vf * DR_GROUP_SIZE (stmt_info) :
vf);
-                 possible_npeel_number
-                   = vect_get_num_vectors (nscalars, vectype);
+                 if (maybe_lt (nscalars, TYPE_VECTOR_SUBPARTS (vectype)))
+                   possible_npeel_number = 0;
+                 else
+                   possible_npeel_number
+                     = vect_get_num_vectors (nscalars, vectype);

                  /* NPEEL_TMP is 0 when there is no misalignment, but also
                     allow peeling NELEMENTS.  */

[Bug tree-optimization/95961] ICE: in exact_div, at poly-int.h:2182

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5c9669a0e6cbf477a03024522943197bdb2682d4

commit r11-1781-g5c9669a0e6cbf477a03024522943197bdb2682d4
Author: Fei Yang <felix.yang@huawei.com>
Date:   Thu Jul 2 10:14:33 2020 +0100

    vect: Fix an ICE in exact_div [PR95961]

    In the test case for PR95961, vectorization factor computed
    by vect_determine_vectorization_factor is [8,8].  But this is
    updated to [1,1] later by vect_update_vf_for_slp.  When we call
    vect_get_num_vectors in vect_enhance_data_refs_alignment, the number
    of scalars which is based on the vectorization factor is not a multiple
    of the the number of elements in the vector type.  This leads to
    the ICE.  This isn't a simple stream of contiguous vector accesses.
    It's hard to predict from the available information how many vector
    accesses we'll actually need per iteration.  As discussed, here we
    should use the number of scalars instead of the number of vectors as
    an upper bound for the loop saving info about DR in the hash table.

    2020-07-02  Felix Yang  <felix.yang@huawei.com>

    gcc/
            PR tree-optimization/95961
            * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Use the
            number of scalars instead of the number of vectors as an upper
bound
            for the loop saving info about DR in the hash table.  Remove unused
            local variables.

    gcc/testsuite/
            PR tree-optimization/95961
            * gcc.target/aarch64/sve/pr95961.c: New test.

[Bug tree-optimization/95961] ICE: in exact_div, at poly-int.h:2182

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

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

--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Fixed.