Spencer Abson <spencer.ab...@arm.com> writes:
> 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.
I don't really agree about the "easier to reason about" bit: IMO,
builtin vector types are the most direct and obvious way of testing
things with fixed-length vectors, for the cases that they can handle
directly. But I agree that vectorisation is more flexible, in that
it can deal with cases that fixed-length builtin vectors can't yet
handle directly.
My main concern was that the tests didn't seem to have much coverage
of normal VLA codegen. If the aim is predictable costing, it might
be enough to use -moverride=sve_width=2048 instead of
-msve-vector-bits=2048.
Thanks,
Richard
