This is the mail archive of the
mailing list for the GCC project.
Re: Draft "Unsafe fp optimizations" project description.
- To: gcc at gcc dot gnu dot org
- Subject: Re: Draft "Unsafe fp optimizations" project description.
- From: "Thomas R. Truscott" <trt at cs dot duke dot edu>
- Date: Sun, 5 Aug 2001 20:43:54 -0400 (EDT)
I instrumented gcc to report "fast-math" optimizations
on a commercial source code that does lots of floating point,
and got the following results:
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 :-)
(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.