[PATCH 2/8] aarch64: Add new +fcma flag

[Andre Vieira (lists)]

On 08/10/2024 17:18, Richard Sandiford wrote:
> Andrew Carlotti <andrew.carlotti@arm.com> writes:
>> This includes +fcma as a dependency of +sve, and means that we can
>> finally support fcma intrinsics on a64fx.
>>
>> Also add fcma to the Features list in several cpunative testcases that
>> incorrectly included sve without fcma.
>>
>> gcc/ChangeLog:
>>
>> 	* config/aarch64/aarch64-arches.def (V8_3A): Add FCMA.
>> 	* config/aarch64/aarch64-option-extensions.def (FCMA): New flag.
>> 	(SVE): Add FCMA dependency.
>> 	* config/aarch64/aarch64.h (TARGET_COMPLEX): Use new flag.
>> 	* config/aarch64/arm_neon.h: Use new flag for fcma intrinsics.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 	* gcc.target/aarch64/cpunative/info_15: Add fcma to Features.
>> 	* gcc.target/aarch64/cpunative/info_16: Ditto.
>> 	* gcc.target/aarch64/cpunative/info_17: Ditto.
>> 	* gcc.target/aarch64/cpunative/info_8: Ditto.
>> 	* gcc.target/aarch64/cpunative/info_9: Ditto.
> 
> In addition to Andrew P's comment about documentation, doesn't this
> mean that -mcpu=native will now emit +fcma .arch strings for
> unrecognised CPUs (i.e. those for which we can't establish a
> baseline beyond Armv8-A?).  E.g., I think:
> 
> processor	: 0
> BogoMIPS	: 100.00
> Features        : fp asimd atomics crc32 asimdrdm paca pacg lrcpc fcma
> CPU implementer	: 0xaa
> CPU architecture: 8
> CPU variant	: 0xaa
> CPU part	: 0xaa
> CPU revision	: 0
> 
> should enable all the Armv8.3-A features that GCC is aware of after
> this patch, but we emit:
> 
>          .arch armv8-a+lse+rdma+crc+fcma+rcpc+pauth
> 
> rather than:
> 
>          .arch armv8.3-a
> 
> And that could be a problem because binutils support for the +fcma
> name is relatively recent (your patch from January this year).
> Assembling with older versions of gas is likely to fail, regardless
> of whether the code uses FCMA.
> 
> I think we might need to adjust the driver code so that it tries
> to consolidate features into an architecture level where possible.
> 
> That does theoretically run the risk of making gas enable features that
> GCC isn't aware of and that aren't available on the CPU (for cases where
> Armv8.X-A+features looks like Armv8.Y-A to GCC, but isn't because of a
> missing feature that GCC doesn't know about).  The current code gets
> that wrong in the opposite direction, though, as the above example
> shows: we wouldn't enable FCMA support even if the target has it.
> 

Just because I think being pedantic here helps, gas doesn't 'enable' but 
rather 'accepts' more than GCC needs it to. The distinction matters here 
because gas will not suddenly generate a binary that has instructions 
that can not run on the target GCC was instructed to compile for (things 
like FMV/using target attributes/simd variants etc aside).

So yeah I agree with Richard that we should still emit armv8.3 in this case.

Kind Regards,
Andre