[PATCH] aarch64: Use target attributes to enable SVE in math functions

[Adhemerval Zanella Netto]

On 30/03/26 13:10, Wilco Dijkstra wrote:
> Hi Adhemerval,
> 
> (adding Joe&Pierre)
> 
>> Instead of relying on global compiler flags ('-mcpu=generic+sve
>> -march=armv8-a+sve') in the Makefile, this patch applies SVE
>> architecture requirements directly at the function level.
>>
>> A new SVE_FUNCTION macro (mapping to
>> __attribute__((target("+sve")))) and corresponding pragmas
>> (OPTIONS_PUSH_SVE / OPTIONS_POP) are introduced in sv_math.h.
>> These are then applied across all SVE-specific math implementations in
>> sysdeps/aarch64/fpu/.
> 
> If we do this, it should be done in the AOR version first so we don't diverge
> any further (and ideally the sources should be more identical).
> 
> Note AOR uses a single target attribute in the header (but then needs a
> pop just for LLVM at the end of each file...).
> 
>> This allows building glibc with a -march without the need to
>> also specify '+sve' (not an usual target, but it helps on testing
>> some target without the need to rebuild the toolchain).
> 
> You can change CFLAGS to use -march= or -mcpu= and it will work. We use
> a generic SVE target for the vector math functions - and that is fine since the
> code is almost exclusively intrinsics. So I'd like to understand what goes wrong
> if you change CFLAGS.

The issue is for a build I added the -march to CFLAGS *and* CPPFLAGS and 
since our make rules adds it *before* CFLAGS it messed which is the default 
-march.

So I think this change is not really required, albeit I still think it would be
a good think to disentangle the required ABI from the Makefile rules.

> 
> In principle we could scan CFLAGS for -mcpu=/-march= and add a +sve
> rather than use a generic target, but that's QoI. I think the only difference it
> would make is emitting RETAA in some helpers if PAC is enabled.

Yeah I agree this would be QoI, but I think it would be better done at source
level instead of make level.