Re: [PATCH] Perform constant folding of math builtins

[Roger Sayle <roger at eyesopen dot com>]

> After reading Geoff Keating's post giving, for example, a/b/c -> a/(b*c)
> as a valid transformation for -funsafe-math-optimizations, I realize it's
> OK to accept sqrt(x)*sqrt(y)->sqrt(x*y) as OK under -ffast-math.
>
> I guess I'm just someone for whom this option does not hold a whole
> lot of promise.

Hi Brad,

I think the situation is far less gloomy than you indicate above.  These
optimizations should benefit much more code than they're likely to break.
I doubt there's any major body of code that would be adversely affected,
and those users that rely on long doubles probably understand the issues
with "-ffast-math" and "-ffloat-store".

I also believe that GCC shouldn't keep "unsafe" optimizations just for
the sake of it.  As soon as a major application, such as GCC, Mozilla,
Linux kernel, SPEC, LAPACK or similar experiences a problem with
"-ffast-math", I'd be more than happy to consider removing the
transformation rather than argue that "-funsafe-math-optimizations"
is intended to be unsafe.

My experience is that many of the FP precision related bugs misposted
to GNATS, e.g. PR other/5574, are due to misunderstandings of floating
point arithmetic, rather then the results of dubious optimizations.

At OpenEye Scientific Software, we use -ffast-math for all our
applications, including grid-based finite difference methods for
solving electrostatics equations.  Having said that we wouldn't
claim our software market is "safety critical" either.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833