[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" <gcc-bugzilla@gcc.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.