> 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