[RFC] Fix PR28684

Clint Whaley whaley@cs.utsa.edu
Wed Nov 15 17:25:00 GMT 2006


At least my mailer freaked out with the mix of Revital's Windows-style
text, and my own unix that I just sent (I can't read the message at all).
Below is what I sent in all unix text . . .

Sorry for the duplication,

>From whaley@cs.utsa.edu  Wed Nov 15 11:20:41 2006
Return-Path: <whaley@cs.utsa.edu>
X-Original-To: whaley@cs.utsa.edu
Delivered-To: whaley@cs.utsa.edu
From: Clint Whaley <whaley@cs.utsa.edu>
Date: Wed, 15 Nov 2006 11:20:41 -0600
To: whaley@cs.utsa.edu
User-Agent: Heirloom mailx 12.0 3/4/06
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail0.cs.utsa.edu
X-Spam-Status: No, score=-4.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,
	MISSING_SUBJECT autolearn=ham version=3.0.2
Status: R


>Following Clint?s recent notes, I returned to the former definition
>of the flag (if no one objects) and tried to clarify the
>documentation  -
|Allow optimization for floating-point arithmetic which are IEEE
|compliant but may not follow language standards by reordering
|the operations and/or commuting operands.
|This means that the result may be changed due to rounding issues.
|For example; in transforming (a + b) + c to a + (b + c) the intermediate
|calculations still follow IEEE standard but the result could be different
|due to rounding which also make the final result different.

>This flag intended for applications that need to be IEEE compliant
>and would like to benefit from some transformations at the price of
>loss of accuracy. 

Since you have split out reciprication, I see no way to have have a loss
of accuracy that is not based on problem order.  Note that if the operands
are not presorted into the best order (very rare, and they cannot throw this
flag) for a particular summing scheme, you are just as likely to get *more*
accuracy with the new order!  Maybe it's in some other transformation
that is not a form reordering that I'm not following?  If this is essentially
only reordering that affects fp results, perhaps the following would be better:

<<<< My suggestion
<This flag intended for applications that must utilize IEEE compliant
<arithmetic and would benefit from the transformations enabled by this flag,
<but do not need to enforce a particular ordering on the individual operations.

|Among the transformations that are enabled by this
|flag are vectorization, mve and re-association.
|An example of a transformation which is not allowed by this flag is
|transforming x * 0 to 0 as the result is not IEEE compliant when x
|is Inf.
|NOTE: may reorder or strength reduce floating-point comparisons as
|well, and so may not be used when ordered comparisons are required.

>It seems that -fassociative-math does not honor signed zero for different
>rounding modes, is that o.k. ?

It doesn't seem obvious to me why reordering the operations messes up the
sign on zero (AFAIK that's not order based?), can you clarify?  As to if
it's OK, like the guys who care about order, I think the times you need
positive/negative zero differentiation are very rare, so it won't keep people
from using the flag.  However, if it can occur, it should probably be mentioned
in the flag definition, as I don't think it is obvious (at least to me) why
it would happen from the present description.  Probably it would be more
obvious if I understood the details of the gcc optimization phases, but
I doubt your average user (even the numerically aware ones) will know this
info either . . .

Much thanks,

More information about the Gcc-patches mailing list