> 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
