Re: Draft "Unsafe fp optimizations" project description.

["Thomas R. Truscott" <trt at cs dot duke dot edu>]

I instrumented gcc to report "fast-math" optimizations
on a commercial source code that does lots of floating point,
and got the following results:

   FREQ TYPE
   2818 x/C => x*(1/C)
    477 x relop x => const
    349 x+0 => x
    158 x*0 => 0
    157 x-0 => x
    126 -(x-y) => y-x
     61 0-x => -x
     35 -x + y -> y-x
     19 x - -y => x+y
      8 0/x => 0
      3 x-x => 0

These are tiny numbers compared to the source code,
and so on average -ffast-math wouldn't have much effect.

The code runs on both IEEE and non-IEEE floating point units,
and so there is no particular dependence on IEEE semantics.
I think all but the ("1/C") optimization would be "safe".

The reports included line numbers (to see what was going on,
e.g. "0. + i" as way to coerce i into floating point)
but that was painful to do in the 'rtx' code.
I had to compile with -g and do other distateful things.
This appears to be a deficiency in gcc.

Now for my biases :-)
#include <std/disclaimer>

(1) I am happy to be in the Linus camp of "non experts",
do not wish to cripple -ffast-math simply to serve my own interests,
and think it should be about as aggressive as it can be.

(2) This code will probably never use the open-ended -ffast-math.
But it could benefit from a subsetted option "-fthumb-nose-at-ieee"
which doesn't worry about -0 or Inf or NaN or denorms.

Tom Truscott