From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27835 invoked by alias); 27 Mar 2004 00:48:34 -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 27747 invoked from network); 27 Mar 2004 00:48:31 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 27 Mar 2004 00:48:31 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i2R0mUGj017906 for ; Fri, 26 Mar 2004 16:48:30 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Fri, 26 Mar 2004 16:48:31 -0800 Received: from [17.201.20.186] (gambrinus.apple.com [17.201.20.186]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i2R0mDGh009928; Sat, 27 Mar 2004 00:48:14 GMT In-Reply-To: <4064CDD6.5030106@gnat.com> References: <20040324170719.A12420@synopsys.com> <16482.60339.544420.228266@gargle.gargle.HOWL> <02BFC253-7E86-11D8-8C7F-000A95D7CD40@apple.com> <4064CDD6.5030106@gnat.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77168DC2-7F88-11D8-8C7F-000A95D7CD40@apple.com> Content-Transfer-Encoding: 7bit Cc: "gcc@gcc.gnu.org list" , Dale Johannesen From: Dale Johannesen Subject: Re: -ffast-math and floating point reordering Date: Sat, 27 Mar 2004 02:39:00 -0000 To: Robert Dewar X-SW-Source: 2004-03/txt/msg01605.txt.bz2 On Mar 26, 2004, at 4:41 PM, Robert Dewar wrote: > Dale Johannesen wrote: >> One point I haven't seen yet: >> A couple of strict-constructionists have asserted that people >> who want reassociation done in a nonstandard way can easily rewrite >> their >> code to achieve this. This is not really true, because such >> expressions >> often arise as a result of other optimizations, in a way that isn't >> obvious >> from the source. Offhand, inlining, unrolling, and constant/copy >> propagation >> can all do it, and there are probably more. > > Well in the absence of the (very annoying) extra precision phenomenon, > none of these optimizations should have observable effects. Untrue. If two of a+b+c are constant, for example, you want to add the constants at compile time (assuming your requirements for accuracy are satisfied). This is exactly the sort of thing that's exposed by other optimiziations.