From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13805 invoked by alias); 26 Mar 2004 17:42:05 -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 13796 invoked from network); 26 Mar 2004 17:42:04 -0000 Received: from unknown (HELO boden.synopsys.com) (198.182.44.79) by sources.redhat.com with SMTP; 26 Mar 2004 17:42:04 -0000 Received: from mother.synopsys.com (mother.synopsys.com [146.225.100.171]) by boden.synopsys.com (Postfix) with ESMTP id AA9C7DBB5; Fri, 26 Mar 2004 09:41:56 -0800 (PST) Received: from piper.synopsys.com (localhost [127.0.0.1]) by mother.synopsys.com (8.9.1/8.9.1) with ESMTP id JAA04841; Fri, 26 Mar 2004 09:42:02 -0800 (PST) Received: (from jbuck@localhost) by piper.synopsys.com (8.11.6/8.11.6) id i2QHg2N03727; Fri, 26 Mar 2004 09:42:02 -0800 X-Authentication-Warning: piper.synopsys.com: jbuck set sender to Joe.Buck@synopsys.com using -f Date: Fri, 26 Mar 2004 18:37:00 -0000 From: Joe Buck To: law@redhat.com Cc: gcc@gcc.gnu.org Subject: Re: -ffast-math and floating point reordering Message-ID: <20040326094202.A2838@synopsys.com> References: <20040324170719.A12420@synopsys.com> <200403261621.i2QGLQ7X014994@speedy.slc.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200403261621.i2QGLQ7X014994@speedy.slc.redhat.com>; from law@redhat.com on Fri, Mar 26, 2004 at 09:21:26AM -0700 X-SW-Source: 2004-03/txt/msg01564.txt.bz2 On Fri, Mar 26, 2004 at 09:21:26AM -0700, law@redhat.com wrote: > In message <20040324170719.A12420@synopsys.com>, Joe Buck writes: > >If -ffast-math is not specified, we should follow the language standards. > >First question: can tree-ssa distinguish, for Fortran, whether parentheses > >were present and so whether reordering is allowed? > No. The front-ends don't pass enough information around in the tree nodes > to know when such changes are safe/unsafe. Even if the information existed > none of the optimizers would know how to use it (at least initially). This should be considered a design bug, as it forces GCC to be inferior to competing Fortran compilers. One possible representation in GIMPLE would be a flag indicating that a temporary can be, well, I'll call it "refactored" (feel free to suggest a better word). That is, given GIMPLE code like t1 = a + b; t2 = t1 + c; e = t2 + d; if the original Fortran input was e = a + b + c + d then t1 and t2 would be tagged as refactorable, while if the original input were d = ((a + b) + c) + d then t1 and t2 would not be so tagged. In the first case, we would probably want to produce t1 = a + b; t2 = c + d; e = t1 + t2; since the first two additions can now be performed in parallel. But this transformation is not legal in the second case. For temporaries marked as refactorable, optimizers are allowed to replace use of the temporary by the expression that computes it, and do transformations on that expression, even if the tranformation doesn't guarantee that roundoffs and overflows will be the same. If the temporary is not marked as refactorable, this is not permitted. With such a rule, the language-independent middle end can implement Fortran or C semantics correctly, and it would be possible to relax the rules in a controlled manner as well:. the user could ask the C front end to implement the Fortran rules (respect parentheses but otherwise allow rearrangement), or the K&R rules (all rearrangements that are correct for real numbers are allowed), but by default the compiler would follow the standard.