Re: Lua and -ffast-math ?

[Miles Bader <miles.bader@...>]

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

-- 
Back, n. That part of your friend which it is your privilege to contemplate in
your adversity.