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

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

On 11/26/2015 01:09 PM, Joseph Myers wrote:
> 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.

Cheers,
Carlos.