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

[Ondřej Bílka]

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.