From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4967 invoked by alias); 26 Mar 2004 18:10:54 -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 4949 invoked from network); 26 Mar 2004 18:10:53 -0000 Received: from unknown (HELO mailout07.sul.t-online.com) (194.25.134.83) by sources.redhat.com with SMTP; 26 Mar 2004 18:10:53 -0000 Received: from fwd08.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1B6vn3-0005YK-03; Fri, 26 Mar 2004 19:10:45 +0100 Received: from kolme (bpeH0UZF8eEvA0Jz5KtH2nS2rUepCk8p0xxNVoElAdTuGnLkB0kzws@[217.94.160.147]) by fmrl08.sul.t-online.com with esmtp id 1B6vms-25I0hM0; Fri, 26 Mar 2004 19:10:34 +0100 Received: from goofy.hamnixda.de ([192.168.100.249] helo=tat.physik.uni-tuebingen.de) by kolme with esmtp (Exim 3.35 #1 (Debian)) id 1B6vmo-0000UR-00; Fri, 26 Mar 2004 19:10:30 +0100 Message-ID: <4064721A.6060905@tat.physik.uni-tuebingen.de> Date: Fri, 26 Mar 2004 19:03:00 -0000 From: Richard Guenther User-Agent: Mozilla Thunderbird 0.5 (X11/20040313) MIME-Version: 1.0 To: Diego Novillo CC: Joe Buck , Jeff Law , "gcc@gcc.gnu.org" Subject: Re: -ffast-math and floating point reordering References: <20040324170719.A12420@synopsys.com> <200403261621.i2QGLQ7X014994@speedy.slc.redhat.com> <20040326094202.A2838@synopsys.com> <1080323297.4600.160.camel@localhost.localdomain> In-Reply-To: <1080323297.4600.160.camel@localhost.localdomain> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Seen: false X-ID: bpeH0UZF8eEvA0Jz5KtH2nS2rUepCk8p0xxNVoElAdTuGnLkB0kzws@t-dialin.net X-SW-Source: 2004-03/txt/msg01568.txt.bz2 Diego Novillo wrote: > On Fri, 2004-03-26 at 12:42, Joe Buck wrote: > > >>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. >> > > Yeah. We sort of discussed adding additional PLUS_EXPR operands and/or > attributes at last year's summit. But I think that was the extent of > it. IIRC, there was beer involved, so I doubt anybody was taking notes. Hmm, this is usually the point where we get the LLVM people tell us what they are doing here... I consider not being able to do something about this in tree-ssa a major defect, too. Richard.