[PATCH 23/25] math: Use erfc from CORE-MATH

[H. Peter Anvin]

On September 16, 2025 9:55:43 AM PDT, Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> wrote:
>
>
>On 11/09/25 19:24, DJ Delorie wrote:
>> Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
>>> The CORE-MATH implementation is correctly rounded for any rounding mode.
>>> The code was adapted to glibc style and to use the definition of
>>> math_config.h (to handle errno, overflow, and underflow).
>>>
>>> Benchtest on x64_64 (Ryzen 9 5900X, gcc 14.2.1), aarch64 (Neoverse-N1,
>>> gcc 13.3.1), and powerpc (POWER10, gcc 13.2.1) shows:
>>>
>>> reciprocal-throughput        master        patched   improvement
>>> x86_64                      49.0980       267.0660      -443.94%
>>> x86_64v2                    49.3220       257.6310      -422.34%
>>> x86_64v3                    42.9539        84.9571       -97.79%
>>> aarch64                     28.7266        52.9096       -84.18%
>>> power10                     14.1673        25.1273       -77.36%
>>>
>>> Latency                      master        patched   improvement
>>> x86_64                      95.6640       269.7060      -181.93%
>>> x86_64v2                    95.8296       260.4860      -171.82%
>>> x86_64v3                    91.1658       112.7150       -23.64%
>>> aarch64                     37.0745        58.6791       -58.27%
>>> power10                     23.3197        31.5737       -35.39%
>> 
>> These are much worse than usual... Do we *want* to slow down this
>> function that much, just for a few ULPs?
>
>This is a good question and I think different developers will have 
>different answers, depending of which kind of workload they intend 
>to use.
>
>My view is that once we start to provide a correctly rounded erf() 
>implementation, it makes sense to also provide an erfc(); otherwise, 
>users might want to use constructions like (1-erf) to get better 
>precision.
>
>But I don't have enough experience to say whether real-world usage 
>requires a correctly rounded implementation. I also tend to view that
>having the standard libraries being correctly rounded is a resource 
>that users can rely on while developing an ad-hoc implementation for 
>specific usage (one can still use multiprecision ones, but they also 
>tend to be orders of magnitude slower).
>
>> 
>>> +  for (int i = 0; i < 22; i++)
>>> +    if (x == exceptions[i][0])
>>> +      return exceptions[i][1] + exceptions[i][2];
>> 
>> IMHO the need for this code implies that all your other algorithms are
>> faulty, if you need to fix their errors...
>> 
>> The exception table could have been sorted, too.
>> 
>>> +  /* subnormal exceptions */
>>> +  if (x == 0x1.a8f7bfbd15495p+4)
>>> +    return fma (0x1p-1074, -0.25, 0x1.99ef5883f656cp-1024);
>> 
>> Could have been part of the exceptions table?
>> 
>
>Afaiu we need also possible FE_UNDERFLOW exception in this case (which
>should be triggered due -frounding-math).

I would think correct rounding would be expected unless -ffast-math is in use, in which case the user is asking specifically to sacrifice ideal precision for performance. 

I don't know if there is some trick with headers that would let -ffast-math invoke a "fast and sloppy" version?