Activate -mrecip with -ffast-math?

[Uros Bizjak]

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.