[PATCH] Perform constant folding of math builtins

[Roger Sayle]

Hi Brad,
> > 	sqrt(x)*sqrt(y) = sqrt(x*y)
> > 	exp(log(x)) = x
>
> This is false for negative x, for obvious reasons.  This could mask
> a real error; I don't think it should be used.

I was relying on the semantics of "-funsafe-math-optimizations", that
to quote the documentation, "allows optimizations for floating-point
arithmetic that assume the arguments and results are valid".

I don't suppose I could convince you this is a reasonable transformation
at GCC's most aggressive level of numerical optimization, namely
"-funsafe-math-optimizations"?  I've had the misfortune to recently
come across sqrt(x)*sqrt(y) in a "real world" example:

> #define len(v) sqrt(v[0]*v[0] + v[1]*v[1] + v[2]*v[2])
>
> double dotprod(double *a, double *b)
> {
>   return (a[0]*b[0] + a[1]*b[1] + a[2]*b[2])/(len(a)*len(b));
> }


I agree that potentially real errors such as sqrt(-1)*sqrt(-1) could
be masked, but if not by "-funsafe-math-optimizations" we'd need another
flag for "unsafe" math optimizations.


Perhaps I could re-interpret your objections as a suggestion to enable
the always-safe transformations at less aggressive levels, for example
with "-ffinite-math-only", which would have the same "-ffast-math"
behavior, but permit the always-safe subset by default in the FORTRAN
front-end?

log(exp(x)) = x should be safe even in the presence of NaNs, signed
infinities and signed zeros, so could be enabled by default unless
"-fsignaling-nans" is specified by the user.  I've left these guarded
by "flag_unsafe_math_optimizations" for the time being lest the user
be surprised by unexpectedly accurate results.

Roger
--