> -----Original Message-----
> From: Richard Biener <rguent...@suse.de>
> Sent: Thursday, July 10, 2025 1:31 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford <richard.sandif...@arm.com>; Tamar Christina
> <tamar.christ...@arm.com>; RISC-V CI <patchworks...@rivosinc.com>
> Subject: [PATCH] Reject single lane vector types for SLP build
> 
> The following makes us never consider vector(1) T types for
> vectorization and ensures this during SLP build.  This is a
> long-standing issue for BB vectorization and when we remove
> early loop vector type setting we lose the single place we have
> that rejects this for loops.
> 
> Once we implement partial loop vectorization we should revisit
> this, but then use the original scalar types for the unvectorized
> parts.

SGTM FWIW,

I was also wondering if I should start upstreaming my changes to
get the vectorizer to recognize vector types as scalar types as well.

Or if you wanted me to wait until I have the lane representations
more figured out.

Regards,
Tamar
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.  I'll see
> if there's any surprises from the CI, but otherwise I'll go
> ahead with this.
> 
> Richard.
> 
>       * tree-vect-slp.cc (vect_build_slp_tree_1): Reject
>       single-lane vector types.
> ---
>  gcc/tree-vect-slp.cc | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> index ad75386926a..d2ce4ffaa4f 100644
> --- a/gcc/tree-vect-slp.cc
> +++ b/gcc/tree-vect-slp.cc
> @@ -1114,6 +1114,15 @@ vect_build_slp_tree_1 (vec_info *vinfo, unsigned char
> *swap,
>        matches[0] = false;
>        return false;
>      }
> +  if (known_le (TYPE_VECTOR_SUBPARTS (vectype), 1U))
> +    {
> +      if (dump_enabled_p ())
> +     dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> +                      "Build SLP failed: not using single lane "
> +                      "vector type %T\n", vectype);
> +      matches[0] = false;
> +      return false;
> +    }
>    /* Record nunits required but continue analysis, producing matches[]
>       as if nunits was not an issue.  This allows splitting of groups
>       to happen.  */
> --
> 2.43.0

Reply via email to