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

[Anton Blanchard <anton at au1 dot ibm dot com>]

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.

Anton