On 07/05/2025 17:28, Richard Earnshaw (lists) wrote:
> 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.
> 

The comment at the head of the function says:

# Multiple instances are supported (since we don't support target and xfail
# selectors on one line), though it doesn't make much sense to change the
# compile/assemble/link/run field.  Nor does it make any sense to have
# multiple lines of target selectors (use one line).

So maybe the code is intended to support multiple reasons for skipping the test 
(but why not use require-effective-target
for that).

I'm not sure now what's going on...

R.

> 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
> 

Reply via email to