Activate -mrecip with -ffast-math?

[Richard Guenther]

On 6/18/07, tbp <tbptbp@gmail.com> wrote:
> On 6/18/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> > Of course there are cases with every optimization enabled by -ffast-math that
> > can break existing programs.  Just that we know of one case beforehand shouldn't
> > prevent us from enabling -mrecip at -ffast-math (provided -mno-recip
> > still works,
> > regardless if provided before or after -ffast-math).  [We'll at least
> > get some more
> > testing coverage this way]
> Argh! Please do not make -ffast-math even more of a pain to work with
> than it is already.
> You have to enable it, on the whole compilation unit, to get anywhere
> near decent performance; there's no escape: either you do not turn it
> on and everything slows to a crawl, or you pay for not being able to
> inline from another unit.
>
> Until now, the contract was: you have to deal with (and contain) NaN
> and infinities. Fair enough, even if tricky that remained manageable.

No, that's not the contract with -ffast-math.  Note that -ffast-math
enables -funsafe-math-optimizations which is allowed to change results
(add/remove rounding operations, contract expressions, do transforms
like a/b to a * 1/b, do transformations that get you bigger errors than
0.5ulp, etc.)

> But if i can't expect a mere division by 0, or sqrt of 0 (quite common
> with FTZ/DAZ on) to give me respectively an infinite and 0 and instead
> get a NaN (which i can't filter, you remember?) because of the NR
> round, that's pure madness.

Hm, which particular case are you concerned about (maybe it was mentioned,
but I don't remember the details)?  Note that -ffast-math enables
-ffinite-math-only as well, so the compiler assumes nothing will result in
NaNs or Infs.

> So please, for the love of everything's sacred, leave such stunts out
> of  -ffast-math.

Well - certainly another reason for the Math BOF ;)  We all expect very
different things from -ffast-math or -funsafe-math-optimizations.

> PS: and it's not like such reciprocals + NR couldn't be done with
> intrinsics or easily handle such common case.

Well, most optimization challenges can be solved if we are allowed to
touch the source ;)

Thanks,
Richard.