On 08/10/2024 17:18, Richard Sandiford wrote:
Andrew Carlotti <andrew.carlo...@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
