This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Fix PR28684
- From: Clint Whaley <whaley at cs dot utsa dot edu>
- To: rguenther at suse dot de, ERES at il dot ibm dot com
- Cc: ZAKS at il dot ibm dot com, whaley at cs dot utsa dot edu, roger at eyesopen dot com, gcc-patches at gcc dot gnu dot org, DORIT at il dot ibm dot com
- Date: Thu, 16 Nov 2006 09:18:15 -0600
- Subject: Re: [RFC] Fix PR28684
- References: <OFE1314467.33CACBB1-ONC2257228.004F50A8-C2257228.004F6098@il.ibm.com>
>If I understand correctly re-ordering can change the result from Inf to a
>non-zero finite number; is that not a problem as well?
OK, I *think* that when reordering changes an Inf to a non-zero finite number,
it is because something that used to underflow to zero no longer does. It
is, in other words, and example of a reordering that obtained greater precision,
not causing a division by zero (for instance), and the number you now have
is a good number, and you don't want Inf. Inf and NaNs usually indicate
something going wrong (except for some funky codes that use them explicitly
for various purposes), and so getting rid of one by performing a more accurate
series of computations is usually a good thing. There are codes that need
to keep ordering exact, and those guys will obviously not be able to throw
the flag. All that said, I don't see how non-division reordering can cause
this behavior, perhaps you can elucidate? I don't recall all the cases where
you get a infinity as an answer (my IEEE book is at work, I'm at home), but
I thought it was mainly division by zero, or an operation involving a
>I believe we may also inhibit or create underflow or overflow with
>re-ordering for example
>(X + C1) - C2 to X + (C1 - C2)
>for X near FLT_MAX and C1 sufficiently large.
I agree it is possible to change things like this. However, this is purely
order-based, so if the user has examined his code and said order doesn't
matter, the overflowed/underflowed or number are all valid IEEE results.
I.e. there are definitely cases where you need this behavior, but you simply
shouldn't throw the flag there.
>Even transforming X + Y - Y to X
>may fail to propagate a NaN Y to the result.
I wasn't sure if general strength reduction was still controlled by the
flag, but if it is, we need to mention it, and again the user can
certify the code as being good in the face of it. I worry a bit about
strength reduction, as it often is unknown how extreme it can get, and
in fp, sometimes it can mess with error (though in small ways). For instance,
replacing 4*X --> X+X+X+X would increase the forward error slightly. Can
we bound the number of extra flops that strength reduction is allowed to do?
Is the strength reduction stuff necessary for vectorization?
> /* In most languages, can't associate operations on floats through
> parentheses. Rather than remember where the parentheses were, we
> don't associate floats at all, unless the user has specified
> -funsafe-math-optimizations. */
Ah, interesting. As a numerical guy, the "reorder unless in paranthesis"
is certainly what I'm used to, but I figured it was the hassle of keeping
track of it that kept you guys from implementing . . .