On 2024-11-04 14:37, Richard Earnshaw (lists) wrote:
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.
Original patch pushed as r14.2.0-357-g66a3827379e.
I'll rework the patch according to your requests for gcc15 and will
include it in my upcoming patchset for -march/mcpu=unset.
Kind regards,
Torbjörn
