This is the mail archive of the
`gcc@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Ian Lance Taylor <ian at wasabisystems dot com>*To*: gcc at gcc dot gnu dot org*Date*: 24 Mar 2004 20:23:41 -0500*Subject*: Re: -ffast-math and floating point reordering*References*: <20040324170719.A12420@synopsys.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

**Follow-Ups**:**Re: -ffast-math and floating point reordering***From:*Robert Dewar

**References**:**-ffast-math and floating point reordering***From:*Joe Buck

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |