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

[Adhemerval Zanella Netto]

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).