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

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Mon, 2015-11-30 at 23:40 -0500, Carlos O'Donell wrote:
> 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.
> 
I agree that we should pursue this direction and deal with the specific
exceptions as they arise. 

Net any effort to avoid unnecessary slow-path execution is good.

> Cheers,
> Carlos.
>