This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Use simpler math functions when user selects -ffast-math


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
joseph@codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]