Making -ffast-math more fine-grained?

Making -ffast-math more fine-grained?

[Nathanael Nerode]

There seem to be an increasing number of different potential "fast math"
changes. (all for floating point, right?... I hope there aren't any integer
"fast math" features)

1 * Ones which allow excess precision computations (these really should be OK
for most people, though not for testsuites)
2 * Ones which ignore correct behavior for anything with NaN or infinities
(and maybe -0.0 vs. +0.0) as intermediate computations, but behave
properly with real numbers (there's probably a class of users who would
appreciate this)
3 * Ones which slightly reduce accuracy by doing truncations instead of
rounding, etc., but where meaningful bounds on the accuracy can be computed
(I'm sure there's a class of users who would appreciate this)
4 * Ones which only work when the exponents involved are close (and are only
useful in cases which should have been coded in fixed-point arithmetic)
such as (a+b)+c => a+(b+c) mentioned by Robert Dewar recently, which are really
dangerous

I think that 1 && 2 && 3 is approximately the current meaning of -ffast-math
(correct me if I'm wrong -- maybe 1 is allowed without -ffast-math, and
disabled by some other switch?), but I'm pretty sure it would be better to
have them as three separate switches.

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/

Re: Making -ffast-math more fine-grained?

[Andrew Pinski]

I thought we have already have some of these flags already, yes we do:

On Mar 23, 2004, at 21:20, Nathanael Nerode wrote:
> 1 * Ones which allow excess precision computations (these really 
> should be OK
> for most people, though not for testsuites)

Done by default on targets which support 80bit math as faster than 
64bit would.
I do not think this is going to change any time soon.

> 2 * Ones which ignore correct behavior for anything with NaN or 
> infinities
> (and maybe -0.0 vs. +0.0) as intermediate computations, but behave
> properly with real numbers (there's probably a class of users who would
> appreciate this)

   -ffinite-math-only          Assume no NaNs or infinities are generated

> 3 * Ones which slightly reduce accuracy by doing truncations instead of
> rounding, etc., but where meaningful bounds on the accuracy can be 
> computed
> (I'm sure there's a class of users who would appreciate this)

   -frounding-math             Disable optimizations that assume default 
FP
                               rounding behavior

> 4 * Ones which only work when the exponents involved are close (and 
> are only
> useful in cases which should have been coded in fixed-point arithmetic)
> such as (a+b)+c => a+(b+c) mentioned by Robert Dewar recently, which 
> are really
> dangerous

   -funsafe-math-optimizations Allow math optimizations that may violate 
IEEE or


There are some which you missed and are unset by -ffast-math (they are 
set by defualt):
   -fmath-errno            Set errno after built-in math functions
   -fsignaling-nans        Disable optimizations observable by IEEE 
signaling NaNs
   -ftrapping-math             Assume floating-point operations can trap


/* The following routines are useful in setting all the flags that
    -ffast-math and -fno-fast-math imply.  */
void
set_fast_math_flags (int set)
{
   flag_trapping_math = !set;
   flag_unsafe_math_optimizations = set;
   flag_finite_math_only = set;
   flag_errno_math = !set;
   if (set)
     {
       flag_signaling_nans = 0;
       flag_rounding_math = 0;
     }
}

Thanks,
Andrew Pinski

Re: Making -ffast-math more fine-grained?

[Roger Sayle]

On Tue, 23 Mar 2004, Andrew Pinski wrote:
> I thought we have already have some of these flags already, yes we do:

An excellent review of -ffast-math!


> On Mar 23, 2004, at 21:20, Nathanael Nerode wrote:
> > 1 * Ones which allow excess precision computations (these really
> > should be OK for most people, though not for testsuites).
>
> Done by default on targets which support 80bit math as faster than
> 64bit would.  I do not think this is going to change any time soon.

This one's command line option is called -ffloat-store, but its neither
enabled nor disabled by -ffast-math, as -fno-float-store is the default.


I appreciate Andrew was listing the fine-grained options of -ffast-math,
but all of Nethanael's categories of transformation are independently
controllable.

Roger
--