On 07/05/2025 17:28, Richard Earnshaw (lists) wrote:
> On 07/05/2025 16:54, Richard Sandiford wrote:
>> Richard Earnshaw <[email protected]> writes:
>>> On 07/05/2025 13:57, Richard Sandiford wrote:
>>>> Kyrylo Tkachov <[email protected]> writes:
>>>>>> On 7 May 2025, at 12:27, Karl Meakin <[email protected]> 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
>
