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, Aug 12, 2015 at 04:45:55PM +0000, Joseph Myers wrote:
> 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?
Ah, when I read code I didn't notice these. I got this when thinking how
to eliminate wrappers. I got idea that we could inline wrapper and teach
gcc dataflow to compute float upper and lower bounds. Currently it couldn't simplify

if (0.0 < x && x < 1.0 && __finite (x))

That would allow add macro to test with builtin_constant_p if function
arguments imply finite result and call function_finite if so.
> > 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.
So first we should document accuracy of these functions, which could
also allow to simplify vector ones when they use same algorithm.

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