Re: RFC: removing slow paths in various dbl-64 libm functions

["Carlos O'Donell" <carlos at redhat dot com>]

On 11/30/2015 07:03 AM, Anton Blanchard wrote:
> Hi Carlos,
> 
>>> I'd like to propose that we consider it OK to remove those slow
>>> paths, and thereby make the functions not correctly rounded, if
>>> this would not result in errors from those functions of more than
>>> 1ulp in round-to-nearest or 2ulp in other rounding modes (this is
>>> stronger than the limits libm-test.inc places on libm function
>>> errors, but might be a longer-term goal for general libm function
>>> accuracy).  The error analysis may be done on the basis of the
>>> existing conditions in those functions for when to use the slow
>>> paths.  For example, in e_asin.c:
>>>
>>>     res = x+t;         /*  res=arcsin(x) according to Taylor
>>> series  */ cor = (x-res)+t;
>>>     if (res == res+1.025*cor) return res;
>> ...
>>> This does not affect cases where multiple-precision slow paths are
>>> needed simply to get results within the normal accuracy goals for
>>> libm functions, or where they are involved in functions that are
>>> fully defined by reference to IEEE 754 operations and so *are*
>>> required to be correctly rounded.
>>
>> This seems good to me.
> 
> Agreed. We've hit these slow paths over the years in benchmarks,
> customer applications and open source code. I was just looking at pow()
> the other week, and every other libm I tested was happy to be at least
> 1 ulp off when testing round to nearest.

Keep in mind these are not the MP fallback paths.

Those higher precision fallback paths are often required just to get
a moderately precise answer. So while this fix might remove some cases where
we were being overly accurate and outside the stated goals, it doesn't
remove cases where we need the accuracy to meet even the minimum goals.
I expect that computations near sharp cuts still require MP solutions to
attain reasonably accurate answers. What users don't like is that the
time taken to compute an answer is not constant, and that might even
constitute a timing oracle in some cases. Either way I think the community
has consensus that we might try an even lower precision libm with constant
runtime via the use of -ffast-math to select an alternate libm with no MP
fallback and higher ULPs. We have discussed this, but have not moved on
the implementation.

Cheers,
Carlos.