Asko Kauppi <askok@dnainternet.net> writes:
Rici Lake recommends in a post from 2005 that "you should never use this
flag" (http://lua-users.org/lists/lua-l/2005-11/msg00192.html).
I think one probably shouldn't compile Lua itself with -ffast-math, as
it's harder to make guarantees about what the Lua programs you load will
want to do, so it seems good to strictly follow the rules for IEEE
floating-point math as best one can.
However it may be fine for the underlying C code [that your Lua code is
an interface to] to be compiled using it, as long as you make sure you
understand how that will interact with the data you will be handling,
and other parts of the system.
Apart from the obvious NaN issues, are there any other subtle reasons
why -ffast-math would be a really bad idea?
The gcc manual says what this option does:
`-ffast-math'
Sets `-fno-math-errno', `-funsafe-math-optimizations',
`-fno-trapping-math', `-ffinite-math-only', `-fno-rounding-math',
`-fno-signaling-nans' and `fcx-limited-range'.
-fno-math-errno: Fine, nobody actually cares about that crap anyway.
-fno-trapping-math: The compiler will generate code assuming
floating-point operations do not trap; this is generally fine
unless you happen to turn on such traps (in which case you can turn
off this assumption explicitly with -ftrapping-math).
-ffinite-math-only: You need to decide whether this is ok or not.
-fno-rounding-math: This is the default gcc behavior anyway.
-fno-signaling-nans: This is the default gcc behavior anyway (has
anyone actually ever used signaling nans?).
-fcx-limited-range: Not sure the real world implication of this.
-funsafe-math-optimizations: This is harder to judge (though it
certainly sounds kind of scary!), but from looking at the gcc
source, mainly it seems to enable use of builtin math functions and
substitutions using math identities that may result in reduced
precision or cause an exception not to be generated,
e.g. optimizing pow(sqrt(x),y) to be pow(x,y*0.5), or tan(atan(x))
to be x.
I think to some degree you have to just trust that the gcc authors
pick these optimizations judiciously, e.g., that "reduced
precision" means "slightly", not "nutso".
[In the gcc source I'm looking at (4.1.something), it also enables
evaluating some expressions at compile-time. Recent gcc versions
use a library that allows bit-accurate evaluation of floating-point
expressions at compile-time, so maybe such evaluations don't depend
on -funsafe-math-optimizations anymore.]
If you depend on every last bit of the result, you probably don't want
to use -ffast-math, but for many applications it's probably fine. You
need to able to judge though...
-Miles
