Re: Is it Okay for GCC to do the following simplifications with "-ffast-math" flag

[Michael Matz <matz at suse dot de>]

Hi,

On Wed, 6 May 2015, Richard Biener wrote:

> >> double f1(int x) { return (double)(float)x; } --> return (double)x;
> >> int f2(double x) { return (int)(float)x; } --> return (int)x;
> >>
> >> Is it Okay for the compiler to do the simplifications shown above with
> >> fast-match enabled?
> >
> >
> > Such a transformation would yield different results
> > for integers that are exactly representable in double
> > but not in float. For example, the smallest positive
> > integer with such a property in IEEE 754, 16,777,217,
> > converts to 16,777,216 in float. I'm not a math expert
> > but such a result would seem unexpected even with
> > -ffast-math.
> 
> Yeah, such changes would be not welcome with -ffast-math.

It's just a normal 1ulp round-off error and these are quite acceptable 
under fast-math.  It just so happens to look large because of the base 
value, and it affects rounded integers.  I don't see how _that_ can be 
used as reason to reject it from fast-math (we'd have to reject pretty 
much all transformation of fast-math then).  Also the above 
transformations are strictly _increasing_ precision, so programs relying 
on fantansy values before should equally be fine with more precise 
fantasy values.

More useful reasons for rejections are: breaks program such-and-such 
(benchmarks), or "no known meaningful performance improvements" (only 
microbenchs for instance).


Ciao,
Michael.