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/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.