This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Use simpler math functions when user selects -ffast-math
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: <andrew dot n dot senkevich at gmail dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 12 Aug 2015 16:45:55 +0000
- Subject: Re: [RFC] Use simpler math functions when user selects -ffast-math
- Authentication-results: sourceware.org; auth=none
- References: <20150811223007 dot GA21338 at domone>
On Wed, 12 Aug 2015, Ondřej Bílka wrote:
> Hi Andrew,
> When I checked isfinite performance I noticed that for most math
> functions wrapper is unnecessary when -ffinite-math-only is set from
> -ffast-math as they evaluate to constant.
It's already the case that -ffinite-math-only causes __*_finite versions
of many libm functions to be used, so bypassing the wrappers. Or do you
mean something other than the math/w_*.c wrappers?
> Adding new symbols would allow to fix bug that due accuracy math
> functions need to be very slow on some inputs. As with -ffast-math you
> don't have to worry much about accuracy we could finally fix these bugs.
As far as I know, we have consensus on the documented accuracy goals for
libm functions, which do *not* require pow, exp, log, sin, cos, tan, asin,
acos, atan or atan2 to be correctly rounded. Thus, various dbl-64
performance issues (bugs 5781, 13932, 17211, at least) could probably be
addressed by removing the very slow multiple-precision cases and allowing
non-correctly-rounded results for some inputs.
*But* simply removing the multiple-precision cases isn't appropriate
without justification that it is safe. That is, each removal needs to
include an error analysis of the existing non-multiple-precision code that
shows why, even if you remove the multiple-precision case, the errors
still won't be too big for any inputs. The error analysis might be fairly
simple, but it does need to be there.
Joseph S. Myers