Spencer Abson <spencer.ab...@arm.com> writes:
> On Thu, Jun 05, 2025 at 06:11:44PM +0100, Richard Sandiford wrote:
>> > diff --git a/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cvtf_3.c
>> > b/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cvtf_3.c
>> > new file mode 100644
>> > index 00000000000..964264c4114
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cvtf_3.c
>> > @@ -0,0 +1,12 @@
>> > +/* { dg-do compile } */
>> > +/* { dg-options "-O2 -ftree-vectorize" } */
>> > +
>> > +#include <stdint.h>
>> > +
>> > +void f64_i32 (double *restrict x, int32_t *restrict y, int n)
>> > +{
>> > + for (int i = 0; i < n; i++)
>> > + x[i] = (double)y[i];
>> > +}
>> > +
>> > +/* { dg-final { scan-assembler-times {\tscvtf\tz[0-9]+\.d, p[0-7]/m,
>> > z[0-9]+\.d\n} 1 } } */
>>
>> I think we should accept \.[sd] for the source, since IMO it would be
>> more natural to do this without the sign-extension to 64 bits.
>> Or have I misunderstood the point of the test?
>
> Ah, sorry - I should have left a comment here. Just to recap, the
> condition used in the integer to float expander:
>
> && (~(<SVE_HSDI:self_mask> | <SVE_HSDI:narrower_mask>) &
> <SVE_F:self_mask>) == 0
>
> Does not cover the extendng SI->DF variant of SCVTF. This means
> that a call to __builtin_convertvector with this pair will be lowered
> peicewise by veclower. However, the vectorizer can always use the
> DI->DF variant here (after a sign-extension), I was OK with this
> and just tested it separately here.
>
> Perhaps it's worth defining floatvnx2sivnx2df2. What do you think?
I don't think this series needs to handle floatvnx2sivnx2df2. The issue
is more that we shouldn't write the test in a way that will fail if that
pattern is added later. I would expect the test to use a .s source if
SI->DF was supported, so I think the test should accept both .s and .d.
Thanks,
Richard
