This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Activate -mrecip with -ffast-math?
On 6/19/07, tbp <tbptbp@gmail.com> wrote:
Indeed there are holes in every direction when you pull in such
transformation, and the cost of plugging every one of them would be
prohibitive; the next batch of c2d supposedly will leave you with ~6
cycles to make it worth for a sqrt.
My C2D has 6 cycles sqrt and 6 cycles div (measured by mubench, not
"from the specs"), but gas_dyn still runs 30% faster with reciprocals.
My point merely was that, considering one operation, you'd introduce
NaN for a not so special value (0) which, in a *fast* math scenario,
could be produced at any previous stage due to denormal clamping; with
no sane way to take care of.
Again, if you look at prior art (icc, AMD's manual...), that's the
only special case they covered.
sqrt(0.0) = NaN is indeed a bit strange. I'll add the trick with
min(x, maxval), as I think is faster than compare + pand.
Admittedly that's a trade off but not that unreasonable.
Now, an option to remove such transformations from -ffast-math
bag-o-tricks would be fine and would still buy gcc some Spec bragging
rights :)
Due to all combinations with rsqrt and rcpss, I'm a bit nervous about
including this by default into -ffast-math. OTOH, can somebody measure
the impact of -mrecip in spec?
Uros.