From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15534 invoked by alias); 25 Mar 2004 01:23:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 15527 invoked from network); 25 Mar 2004 01:23:49 -0000 Received: from unknown (HELO yosemite.airs.com) (209.128.65.135) by sources.redhat.com with SMTP; 25 Mar 2004 01:23:49 -0000 Received: (qmail 26839 invoked by uid 10); 25 Mar 2004 01:23:49 -0000 Received: (qmail 22158 invoked by uid 500); 25 Mar 2004 01:23:41 -0000 From: Ian Lance Taylor To: gcc@gcc.gnu.org Subject: Re: -ffast-math and floating point reordering References: <20040324170719.A12420@synopsys.com> Date: Thu, 25 Mar 2004 06:05:00 -0000 In-Reply-To: <20040324170719.A12420@synopsys.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-03/txt/msg01436.txt.bz2 Joe Buck 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