On 01/11/2024 19:18, Torbjorn SVENSSON wrote:
>
>
> On 2024-11-01 19:40, Richard Earnshaw (lists) wrote:
>> On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
>>> Ok for trunk and releases/gcc-14?
>>>
>>> --
>>>
>>> As these tests are set to execute and require neon hardware to do so,
>>> add the missing dg-require-effective-target arm_neon_hw.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * gcc.target/arm/memset-inline-4.c: Use effective-target
>>> arm_neon_hw.
>>> * gcc.target/arm/memset-inline-5.c: Likewise.
>>> * gcc.target/arm/memset-inline-6.c: Likewise.
>>>
>>> Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com>
>>
>> These tests combine both a scan-assembler and a run. Unconditionally
>> requiring neon hardware before running the test means we lose the
>> scan-assembler when the hardware is not available. But I think you can write
>>
>> /* { dg-do run { arm_neon_hw } } */
>>
>> instead and now the framework will only try to run the test if hardware is
>> available, but will fall back to a compile test otherwise.
>>
>> Would you mind testing that out, please?
>
> Using
>
> /* { dg-do run { target arm_neon_hw } } */
>
> works, but I'm not entirely sure sure what the difference is.
> With both solutions (dg-run and dg-require-effective-target), Cortex-A7 tests
> with -mfloat-abi=soft marks the tests as unsupported. All other targets that
> I test is unchanged.
>
> I suppose that the reason why there is no difference between the two
> suggested solutions is that the tests are skipped if
> arm_tune_string_ops_prefer_neon is not true (the line above my addition in
> the patch).
>
> Let me know if you prefer the dg-require-effective-target or your solution.
> If we go for your solution, should I send a v2 with it?
>
> Kind regards,
> Torbjörn
>
Yeah, this is going to be a bit more invasive than I anticipated. But I do
think we can make this test more widely applicable. It's going to require a
few steps though.
1: I think we need to fix
target-supports.exp(check_effective_target_arm_neon_ok_noncache) to add
-mcpu=unset whenever there's a -march flag in a variant.
2: We need to change the test to not use the skip-if, but to require an
effective target of arm_neon (hence the need for the above)
3: We need to add a -mtune option as well to ensure that the test does use
neon instructions for memcpy operations: adding -mtune=cortex-a7 via
additional-options should achieve that.
With those changes the compile tests should kick in whenever we can
successfully override the default options with something appropriate and the
execution tests should kick in whenever we have neon hardware (the test is not
about whether the performance it great, just whether or not it works).
R.
