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

Richard Biener richard.guenther@gmail.com
Wed May 6 18:24:00 GMT 2015


On May 6, 2015 5:56:10 PM GMT+02:00, Michael Matz <matz@suse.de> wrote:
>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.  

1ulp?  In the double precision result it's more than that.  It's one ulp for the int to float conversion.

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.

Yes, if we think in infinite precision math (maybe that's a good way to document unsafe-math opts, that they can violate IEEE by inter preting  code as written with infinite precision math).

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

Sure.

Richard.

>
>Ciao,
>Michael.




More information about the Gcc mailing list