On 6/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
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.)
I can't expect a division by a constant to survive -ffast-math unscathed, but then that's a change in precision and manageable. Being returned a NaN i'm not supposed to be see for a common case depending on some transformation is something else, entirely.
> 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.
Yes and that's why it's such a pain to handle them correctly while in -ffast-math. But if i generate some, then i get what i've asked for (and i'm in for a local fix). Fair enough. I'm not going to give up ie fast & robust SSE ray/aabb slab tests (or ray/plane or...) because of some arbitrary rule; the hardware handles it just fine (yes there's a penalty, but then it's way faster than branching). For example, when doing 1/x and sqrt(x) via reciprocal + NR, you first get an inf from said reciprocal which then turns to a NaN in the NR stage but if you correct it by, say, doing a comparison to 0 and a 'and'. That's what ICC used to do in your back. That's what you'll find page 151 of the amdfam10 optimization manual. Because that's a common case. As far as i can see, there's no such provision in the current patch. At the very least provide a mean to look after those NaNs without losing sanity, like a way to enforce argument order of min/max[ss|ps|pd] without ressorting to inline asm.
Well - certainly another reason for the Math BOF ;) We all expect very different things from -ffast-math or -funsafe-math-optimizations.
You mean fast & unsafe? I think there's quite a margin between to let someone shoot himself in the feet and put a gun on his head.
