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

[Adhemerval Zanella Netto]

On 03/10/25 12:27, Wilco Dijkstra wrote:
> Hi Adhemerval,
> 
>>> A decade late(!), but it looks good to me. I presume using ifunc to native fma still
>>> has a 2x penalty vs inlining fma like your x86 results show?
>>
>> Yeah, this one seemed a easy one from the math bugzilla backlog we have.
> 
> Yes. Oh I forgot:
> 
> Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com>

Thanks.

> 
>>> What is the penalty if you don't have fma? It seems like the new Coremath functions
>>> will cause significant regressions on older targets that we need to discuss in more...
>>
>> It depends of the symbol, but COREMATH does assumes some facilities to be as
>> fast as usual FP operations (sqrt, fma, rounding).  On the profile I did on armv7
>> with fma build, the main issues for CORE-MATH is the lacking of some rounding
>> functions (round/roundeven) and FP to integer.
> 
> 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. 

> 
>> I think there is still room for improvements on some generic implemetations
>> (like fma); but for other cases I think we will need to come up with different
>> algorithm strategies.
> 
> Yes, fma() is badly written, it can be done many times faster using integer arithmetic
> (which is the obvious approach). But while that should help, it wouldn't solve the
> problem if it still results in a 10x slowdown...
> 
> If we used normal MUL+ADD, does Coremath still produce reasonably accurate results
> or does it fail? Szabolcs and I designed the AOR math functions so that you only lose a
> small amount of ULP if you don't have FMA.

I am not sure for all implementations, but for acoshf I found out that the fma was indeed 
not required [1]. I need to ran all benchmark against x86_64-linux-gnu (or similar ABIs
where fma would be either ifunc route to the soft-float) to check if the fma is a hotspot
on the fast-path.

[1] https://gitlab.inria.fr/core-math/core-math/-/commit/e8774b3a25ff6269ad8626e21d2ce51185ab4e55