This is the mail archive of the 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

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