Andrew Pinski <quic_apin...@quicinc.com> writes:
> The fix for this depends on much more infrastructure which won't
> be done for another few weeks. Pengxuan is working on the fix for GCC 16.
> So let's xfail the testcase since it is a minor code quality regression.
> we get:
> ```
> movi v0.2s, 0
> ins v0.h[0], w0
> ```
> vs what we should get:
> ```
> and x0, x0, 65535
> fmov d0, x0
> ```
> or
> ```
> fmov h0, x0
> ```
>
> Tested for aarch64-linux-gnu.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/pr109072_1.c: xfail s16x4_2.
OK, thanks. Previously we handled this by treating the operation as
a HI->DI zero_extend. I was wondering whether we should add a special
case to aarch64_expand_vector_init for that: extend the low element and
then bitcast. That should handle QI->DI as well, unlike FMOV.
We would do the extension in GPRs and then use a FMOV D.
But that could be counterproductive in some cases, especially if the
scalar element is in memory. It could mean that we force elements
into GPRs that might not otherwise have needed them. So I agree that
this testsuite failure should be treated as part of Pengxuan's FMOV work.
Richard
> Signed-off-by: Andrew Pinski <quic_apin...@quicinc.com>
> ---
> gcc/testsuite/gcc.target/aarch64/pr109072_1.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr109072_1.c
> b/gcc/testsuite/gcc.target/aarch64/pr109072_1.c
> index 0fc195a598f..39d80222142 100644
> --- a/gcc/testsuite/gcc.target/aarch64/pr109072_1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/pr109072_1.c
> @@ -77,7 +77,8 @@ s16x4_1 (int16_t x)
> }
>
> /*
> -** s16x4_2:
> +PR target/117092
> +** s16x4_2: { xfail *-*-* }
> ** ...
> ** fmov [dsh]0, [wx][0-9]+
> ** ret
> @@ -127,7 +128,7 @@ s64x2_1 (int64_t x)
> }
>
> /*
> -** s64x2_2: { xfail *-*-* }
> +** s64x2_2:
> ** fmov d0, x0
> ** ret
> */
