On 04/11/2024 12:28, Torbjorn SVENSSON wrote:
>
>
> On 2024-11-04 12:44, Richard Earnshaw (lists) wrote:
>> 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).
>
> Can we do this as a 2 parted process?
> With the first part, I would like to avoid running it in configuration where
> it's known to fail and this part should ideally be retrofired to gcc14.
I'd prefer not to do that as it creates a user-visible change in a dot release
of the compiler.
> For the 2nd part, I agree with the steps above, but that will only be
> applicable for gcc15, unless you also want to backport the
> -mcpu=unset/-march=unset feature to gcc14 too.
>
> Can we do the first part in this patch and then come back to part 2
> afterwards?
I'd be happy for completely separate patches to go in on gcc-14 and on trunk -
feel free to apply your original patch to the gcc-14 branch while we work on a
full fix for gcc-15.
>
> Kind regards,
> Torbjörn
R.
