[RFC] Fix PR28684

[Richard Guenther]

On 11/15/06, Clint Whaley <whaley@cs.utsa.edu> wrote:
> Guys,
>
> 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,
> Clint
>
> 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-Level:
> 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
>
> Revital,
>
> >Following Clint?s recent notes, I returned to the former definition
> >of the flag (if no one objects) and tried to clarify the
> >documentation  -
> >
> |-fassociative-math:
> |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.
>
> >>>>original
> >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 . . .

Yes, re-ordering can mess with signedness of zero, so I agree it should
be mentioned (and such transformations should not be excluded
from -fassociative-math just because sign of zero may be changed).
Usually people do care less about the sign of zero and rather want
proper overflow (Inf) behavior and propagation of NaNs.

Richard.