> Could you walk me through the failure in more detail?  It sounds
> like can_duplicate_and_interleave_p eventually gets to the point of
> subdividing the original elements, instead of either combining consecutive
> elements (the best case), or leaving them as-is (the expected fallback
> for SVE).  But it sounds like those attempts fail in this case, but an
> attempt to subdivide the elements succeeds.  Is that right?  And if so,
> why does that happen?

Apologies for the very late response.

What I see is that we start with a base_vector_type vector([1,1]) long int
and a count of 2, so ELT_BYTES = 16.
We don't have a TI vector mode (and creating a single-element vector by
interleaving is futile anyway) so the first attempt fails.
The type in the second attempt is vector([1,1]) unsigned long but this
is rejected because of

  && multiple_p (GET_MODE_NUNITS (TYPE_MODE (vector_type)),                     
                                                                                
      │
                 2, &half_nelts))

Then we try vector([2,2]) unsigned int which "succeeds".  This, however,
eventually causes the ICE when we try to build a vector with 0 elements.

Maybe another option would be to decline 1-element vectors right away?

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index eac16e80ecd..d3e52489fa8 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -427,7 +427,9 @@ can_duplicate_and_interleave_p (vec_info *vinfo, unsigned 
int count,
                                tree *permutes)
 {
   tree base_vector_type = get_vectype_for_scalar_type (vinfo, elt_type, count);
-  if (!base_vector_type || !VECTOR_MODE_P (TYPE_MODE (base_vector_type)))
+  if (!base_vector_type
+      || !VECTOR_MODE_P (TYPE_MODE (base_vector_type))
+      || maybe_lt (GET_MODE_NUNITS (TYPE_MODE (base_vector_type)), 2))
     return false;

Regards
 Robin

Reply via email to