On 07/05/2025 16:54, Richard Sandiford wrote:
> Richard Earnshaw <richard.earns...@arm.com> writes:
>> On 07/05/2025 13:57, Richard Sandiford wrote:
>>> Kyrylo Tkachov <ktkac...@nvidia.com> writes:
>>>>> On 7 May 2025, at 12:27, Karl Meakin <karl.mea...@arm.com> wrote:
>>>>>
>>>>> Commit the test file `cmpbr.c` before rules for generating the new
>>>>> instructions are added, so that the changes in codegen are more obvious
>>>>> in the next commit.
>>>>
>>>> I guess that’s an LLVM best practice.
>>>> In GCC since we have the check-function-bodies mechanism we usually prefer
>>>> to include the relevant test together with the patch that adds the
>>>> optimization.
>>>> But this is not wrong either.
>>>>
>>>>
>>>>>
>>>>> gcc/testsuite/ChangeLog:
>>>>>
>>>>> * gcc.target/aarch64/cmpbr.c: New test.
>>>>> ---
>>>>> gcc/testsuite/gcc.target/aarch64/cmpbr.c | 1378 ++++++++++++++++++++++
>>>>> 1 file changed, 1378 insertions(+)
>>>>> create mode 100644 gcc/testsuite/gcc.target/aarch64/cmpbr.c
>>>>>
>>>>> diff --git a/gcc/testsuite/gcc.target/aarch64/cmpbr.c
>>>>> b/gcc/testsuite/gcc.target/aarch64/cmpbr.c
>>>>> new file mode 100644
>>>>> index 00000000000..728d6ead91c
>>>>> --- /dev/null
>>>>> +++ b/gcc/testsuite/gcc.target/aarch64/cmpbr.c
>>>>> @@ -0,0 +1,1378 @@
>>>>> +/* Test that the instructions added by FEAT_CMPBR are emitted */
>>>>> +/* { dg-do compile } */
>>>>> +/* { dg-options "-march=armv9.5-a+cmpbr -O2" } */
>>>>> +/* { dg-final { check-function-bodies "**" "" "" } } */
>>>>
>>>> As you’ll be adding new instructions to the compiler it’d be good to have
>>>> it a dg-do assemble test where possible.
>>>
>>> Agreed FWIW, but:
>>>
>>>> For that you’ll need to create a new aarch64_asm_cmpbr_ok target and use
>>>> it like so to fallback to dg-do compile when the assembler is too old:
>>>> /* { dg-do compile { target aarch64_asm_cmpbr_ok } } */
>>>
>>> ...dg-do assemble for this one :)
>>
>> I don't think that works. If the first dg-do fails the test is just skipped.
>>
>> You need to replicate the test with separate dg-do directives, IIRC.
>
> Hmm, can you remember the circumstances when you saw that?
> We've been using the construct that Kyrill suggested with apparent
> success in things like aarch64-sve2-acle-asm.exp. E.g.:
Well, the implementation of dg-do contains the comment:
# Note: A previous occurrence of `dg-do' with target/xfail selectors
# is a user mistake. We clobber previous values here.
So one might interpret that as meaning multiple dg-do's are not intended to be
supported.
But I might have misremembered the exact scenario I was facing. I think it
might have been that a test failed to fall back to the dg-do-default if a
specific dg-do didn't match. The scenario I remember was something like
dg-do-default = compile, then the test was trying to change that to execute if
HW was available; but that meant that if it wasn't we didn't fall back to
checking the assembler output.
R.
>
> /* { dg-do assemble { target aarch64_asm_sve2p1_ok } } */
> /* { dg-do compile { target { ! aarch64_asm_sve2p1_ok } } } */
> /* { dg-final { check-function-bodies "**" "" "-DCHECK_ASM" } } */
>
> If I run this normally, it picks the assemble route (tests run with -c).
> If I force aarch64_asm_sve2p1_ok to false by mangling the test
> instruction, the test picks the compile route (tests with run -S).
>
> Thanks,
> Richard
