From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8385 invoked by alias); 25 Mar 2004 18:59:03 -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 8366 invoked from network); 25 Mar 2004 18:59:02 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 25 Mar 2004 18:59:02 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id 725EEF2830; Thu, 25 Mar 2004 13:59:02 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11795-01-2; Thu, 25 Mar 2004 13:59:02 -0500 (EST) Received: from [205.232.38.124] (potomac.gnat.com [205.232.38.124]) by nile.gnat.com (Postfix) with ESMTP id 2F1A8F2D56; Thu, 25 Mar 2004 13:59:02 -0500 (EST) In-Reply-To: <02BFC253-7E86-11D8-8C7F-000A95D7CD40@apple.com> References: <20040324170719.A12420@synopsys.com> <16482.60339.544420.228266@gargle.gargle.HOWL> <02BFC253-7E86-11D8-8C7F-000A95D7CD40@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7A0CB2F0-7E8E-11D8-9B91-000A959A128E@gnat.com> Content-Transfer-Encoding: 7bit Cc: "gcc@gcc.gnu.org list" From: Geert Bosch Subject: Re: -ffast-math and floating point reordering Date: Thu, 25 Mar 2004 20:11:00 -0000 To: Dale Johannesen X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-03/txt/msg01502.txt.bz2 On Mar 25, 2004, at 12:58, 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. > This is a good point, and it also serves as an illustration of weaknesses in the "just add another command-line option" philosophy. For example, in writing various elementary floating-point functions, it definitely is necessary to prevent unsafe transformations in order to attain accuracy requirements for the entire domain of the function. On the other hand, it is also desirable in many cases to inline these functions, especially when one of the operands is a constant. How can we specify that this code that relies on strict semantics will not be affected by the command-line options. A similar issue exists the other way around. There may be library functions where the various transformations are known to be safe, and which may benefit from them. Think of a graphics routines for coordinate transformations for example. One solution seems to allow having tree-level operations for addition, multiplications etc. that specify wether they are - associative - communicative - potentially trapping - supporting non-finite value semantics - supporting non-default rounding This way front ends can set these attributes depending on language rules and/or constructs in the source specifying certain behavior. -Geert