Re: -ffast-math and floating point reordering

[Ian Lance Taylor <ian at wasabisystems dot com>]

Joe Buck <Joe.Buck@synopsys.COM> writes:

> If -ffast-math is specified, what should we do?  One option is to use the
> K&R rule and free-associate at will.  I feel uncomfortable with that
> because of the major loss in accuracy that can result.  If, however, we
> implement support for the Fortran rules, one option would be to relax
> order of evaluation when there are no parentheses (like Fortran), another
> would be to just leave the order the same.

-ffast-math is documented in terms of turning on a set of other
options.  So another issue is: if we add support for permitting the
addition of a+b+c in any order, should we put that under
-funsafe-math-optimizations (currently implied for -ffast-math), or
should we put it under another option (-fassociative-math?).  If we
choose the latter alternative, should that new option be set by
-ffast-math, or only by explicit use?

My vote, at least right now, would be to add -fassociative-math to
mean that gcc is permitted to reassociate math expressions at will,
regardless of the presence of parentheses.  And -ffast-math should
imply -fassociative-math.  That is, with -ffast-math, (a+b)+c may be
evaluated as a+(b+c).

My rationale is that people who are paying close attention to their
floating point arithmetic should generally not use -ffast-math.  But
adding another option for this will permit people to pay close
attention to floating point arithmetic to use -ffast-math
-fno-associative-math.  In general I'm not in favor of giving people
too many knobs.  But I think this one is OK because it can be clearly
expressed in terms of its effect on the code that people write (as
opposed to many of the knobs which are expressed in terms of gcc's
internal optimizations).

People who do not pay close attention to floating point arithmetic,
and who use -ffast-math, are saying that they want the fastest
possible execution, and that their floating point code is written
accordingly.  I believe that implies that reassociating floating point
operations is acceptable when it will produce faster code.

I don't think this type of reassociation fits under
-funsafe-math-options, because it doesn't really fit the description
of that option in the documentation.  That option is described in
terms of assuming that values are in domain and results are in range.
That is different from associativity.

Ian