On Thu, Jun 05, 2025 at 09:24:27PM +0100, Richard Sandiford wrote:
> Spencer Abson <spencer.ab...@arm.com> writes:
> > diff --git a/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cond_cvtf_1.c
> > b/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cond_cvtf_1.c
> > new file mode 100644
> > index 00000000000..8f69232f2cf
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cond_cvtf_1.c
> > @@ -0,0 +1,47 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -ftree-vectorize -msve-vector-bits=2048
> > -fno-trapping-math" } */
>
> The =2048 is ok, but do you need it for these autovectorisation tests?
> If vectorisation is treated as not profitable without it, then perhaps
> we could switch to Tamar's -mmax-vectorization, once that's in.
This isn't needed to make vectorization profitable, but rather to
make partial vector modes the reliably obvious choice - and hopefully
one that is isn't affected by future cost model changes. With =2048
and COUNT, each loop should be fully-unrolled into a single unpacked
operation (plus setup and return).
For me, this was much more flexible than using builtin vector types,
and easier to reason about. Maybe that's just me though! I can try
something else if it would be preferred.
>
> OK as-is, but also ok without -msve-vector-bits if that works (first
> preference) or with -mmax-vectorization (second preference).
>
> Thanks,
> Richard
