[PATCH] arm: Add ARM VFPv4 VFMA instruction support in fma/fmaf (BZ 15503)

[Adhemerval Zanella Netto]

On 28/10/25 15:55, Wilco Dijkstra wrote:
> Hi Adhemerval,
> 
>>> If an ifunc using native FMA has a 2x slow down vs inline FMA, are we talking about
>>> a 10-25x hit with emulated fma()???
>>
>> I will need to get some real number to give you a better answer, but I recall that
>> running x86_64-linux-gnu without multiarch I saw pretty bad results that something
>> that 10x indeed.
> 
> So I did some quick runs on the new atanh/asinh/acosh on Arm, and it looks FMA
> ifunc has ~50% overhead over inlined FMA, and emulated FMA is 15 times slower
> than inline FMA (and 10x ifunc FMA).

I think I might eventually do the same analysis to check if all the fma operations
are really required to provide correctly rounded results.

As a side note, gcc already does something like -fno-plt for internal ifunc usage?
If not, I think we could remove some of the overhead.

Another possibility would add a hwcap support for armhf for vpfv4, and work with
distro to enable a libm.so optimized for it.

It is also on my backlog to check if we can consolidate all the generic double
fma implementation on only one.  Current we have:

  sysdeps/ieee754/dbl-64/s_fma.c
  sysdeps/ieee754/ldbl-96/s_fma.c 
  sysdeps/ieee754/ldbl-128/s_fma.c
  sysdeps/ieee754/soft-fp/s_fma.c
  
All but the sofp-fp uses the floating-point exceptions to change rounding and
check for exceptions. I think the soft-fp would most likely be a better
default even for ldbl-96/ldbl-128.