[Bug middle-end/112661] New: [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

[Bug middle-end/112661] New: [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

[patrick at rivosinc dot com]

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

            Bug ID: 112661
           Summary: [14] RISC-V ICE: in duplicate_and_interleave, at
                    tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Found on pr112597, GCC hash: 30d8188e6d1b450533ab0055b951ebfc75022219
Replicated using 7a496b7ce105185be12e023e749c90d5f7561879 since that's what I
had on hand.

> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv64gcv_zvl256b -mabi=lp64d -O3 maxval_char_3.f90 -freport-bug
during GIMPLE pass: vect
maxval_char_3.f90:2:12:

    2 | program main
      |            ^
internal compiler error: in duplicate_and_interleave, at tree-vect-slp.cc:8025
0xa8fb27 duplicate_and_interleave(vec_info*, gimple**, tree_node*,
vec<tree_node*, va_heap, vl_ptr> const&, unsigned int, vec<tree_node*, va_heap,
vl_ptr>&)
        ../../../gcc/gcc/tree-vect-slp.cc:8025
0x15e04b5 vect_create_constant_vectors
        ../../../gcc/gcc/tree-vect-slp.cc:8246
0x15e04b5 vect_schedule_slp_node
        ../../../gcc/gcc/tree-vect-slp.cc:9052
0x15f39ff vect_schedule_scc
        ../../../gcc/gcc/tree-vect-slp.cc:9433
0x15f4698 vect_schedule_scc
        ../../../gcc/gcc/tree-vect-slp.cc:9450
0x15f4da7 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
        ../../../gcc/gcc/tree-vect-slp.cc:9614
0x15c3aeb vect_transform_loop(_loop_vec_info*, gimple*)
        ../../../gcc/gcc/tree-vect-loop.cc:11710
0x1605791 vect_transform_loops
        ../../../gcc/gcc/tree-vectorizer.cc:1006
0x1605f03 try_vectorize_loop_1
        ../../../gcc/gcc/tree-vectorizer.cc:1152
0x1605f03 try_vectorize_loop
        ../../../gcc/gcc/tree-vectorizer.cc:1182
0x1606514 execute
        ../../../gcc/gcc/tree-vectorizer.cc:1298
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

-freport bug does not seem to generate any output so please let me know if you
need any additional info:

> ./bin/riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=./bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/scratch/tc-testing/bisect-issue/hash-7a496b7ce105185be12e023e749c90d5f7561879/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with:
/scratch/tc-testing/bisect-issue/hash-7a496b7ce105185be12e023e749c90d5f7561879/../gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/scratch/tc-testing/bisect-issue/hash-7a496b7ce105185be12e023e749c90d5f7561879
--with-sysroot=/scratch/tc-testing/bisect-issue/hash-7a496b7ce105185be12e023e749c90d5f7561879/sysroot
--with-pkgversion=g7a496b7ce10 --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=../../gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc
--with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2   
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2    -mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231116 (experimental) (g7a496b7ce10)

Source file:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gfortran.dg/maxval_char_3.f90;h=cc41ae049fb4920f0148f9c470071d6b940527c4;hb=7a496b7ce105185be12e023e749c90d5f7561879

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

[rdapp at gcc dot gnu.org]

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

--- Comment #1 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Confirmed, smaller example:

program main
  implicit none
  integer, parameter :: n=5
  character(len=6), dimension(n,n) :: a
  character(len=6), dimension(n) :: r1
  integer :: i
  logical, dimension(n,n) :: mask

  write (unit=a,fmt='(I6.6)') (i*i+200-17*i,i=1,n*n)
  mask = .true.
  forall (i=1:n)
     mask(i,i) = .false.
  end forall

  r1 = maxval(a, dim=1, mask=mask)

end program main

compiled with -O3 -march=rv64gcv_zvl256b

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

[juzhe.zhong at rivai dot ai]

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

--- Comment #2 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Robin Dapp from comment #1)
> Confirmed, smaller example:
> 
> program main
>   implicit none
>   integer, parameter :: n=5
>   character(len=6), dimension(n,n) :: a
>   character(len=6), dimension(n) :: r1
>   integer :: i
>   logical, dimension(n,n) :: mask
> 
>   write (unit=a,fmt='(I6.6)') (i*i+200-17*i,i=1,n*n)
>   mask = .true.
>   forall (i=1:n)
>      mask(i,i) = .false.
>   end forall
> 
>   r1 = maxval(a, dim=1, mask=mask)
> 
> end program main
> 
> compiled with -O3 -march=rv64gcv_zvl256b

Thanks Robin.

I am gonna work on C/C++ bugs. You work on fortran so that we won't do
duplicate 
work. Is that OK for you ?

Thanks.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

[rdapp at gcc dot gnu.org]

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

--- Comment #3 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Yes, as agreed. Though today I probably won't be able to do much due to private
matters.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |rsandifo at gcc dot gnu.org
   Last reconfirmed|                            |2023-11-22
             Status|UNCONFIRMED                 |NEW

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
We are code-generating

t.f90:1:12: note: node (constant) 0x53bc430 (max_nunits=1, refcnt=1)
vector([8,8]) unsigned int
t.f90:1:12: note:  { 1, 1, 1, 1, 1 }

during SLP node analysis we assume we can constant generate constants/externals
as only consumers will determine the vector type.  vectorizable_store
doesn't verify it can generate the constant though.  Instead we are checking
this at SLP build time.

We're using E_RVVM1SImode as base_vector_mode and count is 5.  There's
obviously no integer mode for size '5'.  But it is a constant size vector
so I wonder why we ask for can_duplicate_and_interleave_p at all, that is,
how we arrive at vector([8,8]) for a constant size vinfo->vector_mode.

At analysis time we do

          if ((dt == vect_constant_def
               || dt == vect_external_def)
              && !GET_MODE_SIZE (vinfo->vector_mode).is_constant ()
              && TREE_CODE (type) != BOOLEAN_TYPE
              && !can_duplicate_and_interleave_p (vinfo, stmts.length (),
type))
            {      

see how we look at vinfo->vector_mode here.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14] RISC-V ICE: in         |[14] RISC-V ICE: in
                   |duplicate_and_interleave,   |duplicate_and_interleave,
                   |at tree-vect-slp.cc:8025    |at tree-vect-slp.cc:8025
                   |with maxval_char_3.f90      |with maxval_char_3.f90
                   |vlen256b                    |vlen256b since
                   |                            |r14-5101-g60034ecf25597b

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, a fallout of r14-5101-g60034ecf25597b.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
As suggested in the review at time the change would ideally be restricted to
actual mask operands, not random BOOLEAN_TYPE ones.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 4a09b3c2aca..d0967240ae3 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -766,7 +766,10 @@ vect_get_and_check_slp_defs (vec_info *vinfo, unsigned
char swap,
          if ((dt == vect_constant_def
               || dt == vect_external_def)
              && !GET_MODE_SIZE (vinfo->vector_mode).is_constant ()
-             && TREE_CODE (type) != BOOLEAN_TYPE
+             && (!is_gimple_call (stmt_info->stmt)
+                 || !gimple_call_internal_p (stmt_info->stmt)
+                 || internal_fn_mask_index
+                      (gimple_call_internal_fn (stmt_info->stmt)) != opno)
              && !can_duplicate_and_interleave_p (vinfo, stmts.length (),
type))
            {
              if (dump_enabled_p ())

fixes the testcase, not sure if it still resolves the issue fixed with the
original change.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
I think we're going down the wrong path here.  If I've understood
the original change correctly, dummy masks aren't special because
they're masks.  They're special because all elements are equal to
the same value.  A mask such as:

  { 1, 1, 1, 0, 1 }

would not be OK, just like an integer vector with those values would
not be OK.

So IMO we should check whether all elements are equal, rather than
whether the type is one thing or another.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Sandiford from comment #8)
> I think we're going down the wrong path here.  If I've understood
> the original change correctly, dummy masks aren't special because
> they're masks.  They're special because all elements are equal to
> the same value.  A mask such as:
> 
>   { 1, 1, 1, 0, 1 }
> 
> would not be OK, just like an integer vector with those values would
> not be OK.
> 
> So IMO we should check whether all elements are equal, rather than
> whether the type is one thing or another.

So do we expect - independed of whether a constant/external is used as mask -
that uniform constants/externals are generatable and thus we can elide the
check for those?  Possibly also go a different path during code-generation
then?  (because that will otherwise assert)

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> So do we expect - independed of whether a constant/external is used as mask
> - that uniform constants/externals are generatable and thus we can elide the
> check for those?  Possibly also go a different path during code-generation
> then?  (because that will otherwise assert)
Yeah, I think so.  At the time, I don't think there were any cases where
treating uniform values differently would have helped, and it wasn't
trivial thing to test on the fly.  But now we have a reason to try :)

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, I'll give that a try then.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 56668
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56668&action=edit
patch  (not working)

So this tries this, moving the duplicate-and-interleave check and changing
code generation.  It seems though that gimple_build_vector_from_val only
uses VEC_DUPLICATE_EXPR for non-constants but tree-vector-builder doesn't
like to build the uniform constant and we ICE:

internal compiler error: in finalize, at vector-builder.h:513
0x1e36958 vector_builder<tree_node*, tree_node*,
tree_vector_builder>::finalize()
  /space/rguenther/src/gcc/gcc/vector-builder.h:513
0x1e36598 tree_vector_builder::build()
  /space/rguenther/src/gcc/gcc/tree-vector-builder.cc:42
0x15dc80a gimple_build_vector(gimple_stmt_iterator*, bool, gsi_iterator_update,
unsigned int, tree_vector_builder*)
  /space/rguenther/src/gcc/gcc/gimple-fold.cc:9256
0x1ddb2e7 gimple_build_vector(gimple**, tree_vector_builder*)
  /space/rguenther/src/gcc/gcc/gimple-fold.h:241
0x1e0d6f5 vect_create_constant_vectors
  /space/rguenther/src/gcc/gcc/tree-vect-slp.cc:8261

that's the assert

508  void
509  vector_builder<T, Shape, Derived>::finalize ()
510  {
511    /* The encoding requires the same number of elements to come from each
512       pattern.  */
513    gcc_assert (multiple_p (m_full_nelts, m_npatterns));

I can of course try to manually build a VEC_DUPLICATE here but I wonder
if we're on the right track here.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rsandifo at gcc dot gnu.org]

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

--- Comment #13 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
In vect_create_constant_vectors, I think the uniform_elt needs
to come first, and needs to be used irrespective of whether the
number of elements is constant.  The general tree_vector_builder
has a more general pattern than 1 duplicated element.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Sandiford from comment #13)
> In vect_create_constant_vectors, I think the uniform_elt needs
> to come first, and needs to be used irrespective of whether the
> number of elements is constant.  The general tree_vector_builder
> has a more general pattern than 1 duplicated element.

can you take it from here since I have limited means to test?

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rsandifo at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|rguenth at gcc dot gnu.org         |rsandifo at gcc dot gnu.org

--- Comment #15 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
Sure.  SVE doesn't exhibit the ICE as far as I can tell, but a modified
version passes testing on SVE, and seems to fix an XFAIL.  I'll test
more widely overnight and post tomorrow.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:061a82fa2b751b42d0d8ddfcd45367c848d3ee64

commit r14-5878-g061a82fa2b751b42d0d8ddfcd45367c848d3ee64
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Mon Nov 27 13:38:16 2023 +0000

    vect: Avoid duplicate_and_interleave for uniform vectors [PR112661]

    can_duplicate_and_interleave_p checks whether we know a way of
    building a particular VLA SLP invariant.  g:60034ecf25597bd515f
    skipped that test for booleans, to support MASK_LEN_GATHER_LOAD
    calls with a dummy all-ones mask.  But there's nothing fundamentally
    different about VLA masks vs VLA data vectors.  If we have a VLA mask
    that isn't all-ones, we need some way of loading it.  This ultimately
    led to the ICE in the PR.

    This patch fixes it by applying can_duplicate_and_interleave_p
    to masks, while also adding a special path for uniform vectors
    (of all kinds) to support the MASK_LEN_GATHER_LOAD usage.  This
    also fixes an XFAIL in pr36648.cc for SVE.

    The patch is mostly Richard's.  My only changes were to skip
    redundant conversions and to use gimple_build_vector_from_val
    for all eligible vectors.

    2023-11-27  Richard Biener  <rguenther@suse.de>
                Richard Sandiford  <richard.sandiford@arm.com>

    gcc/
            PR tree-optimization/112661
            * tree-vect-slp.cc (vect_get_and_check_slp_defs): Defer
duplicate-and-
            interleave test to...
            (vect_build_slp_tree_2): ...here, once we have all the operands.
            Skip the test for uniform vectors.
            (vect_create_constant_vectors): Detect uniform vectors.  Avoid
            redundant conversions in that case.  Use
gimple_build_vector_from_val
            to build the vector.

    gcc/testsuite/
            * g++.dg/vect/pr36648.cc: Remove XFAIL for VLA load-lanes.

[Bug tree-optimization/112661] [14] RISC-V ICE: in duplicate_and_interleave, at tree-vect-slp.cc:8025 with maxval_char_3.f90 vlen256b since r14-5101-g60034ecf25597b

[rsandifo at gcc dot gnu.org]

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

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

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

--- Comment #17 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
Assuming fixed.  Please reopen if there are lingering issues.