This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: removing slow paths in various dbl-64 libm functions
- From: Anton Blanchard <anton at au1 dot ibm dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 30 Nov 2015 23:03:24 +1100
- Subject: Re: RFC: removing slow paths in various dbl-64 libm functions
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511261736421 dot 10502 at digraph dot polyomino dot org dot uk> <5657D3A5 dot 5090005 at redhat 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