From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9852 invoked by alias); 26 Mar 2004 18:18:52 -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 9845 invoked from network); 26 Mar 2004 18:18:50 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 26 Mar 2004 18:18:50 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i2QIInQX011881 for ; Fri, 26 Mar 2004 10:18:49 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Fri, 26 Mar 2004 10:18:49 -0800 Received: from [17.201.21.188] (jahan5.apple.com [17.201.21.188]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i2QIIlRO024308; Fri, 26 Mar 2004 18:18:48 GMT In-Reply-To: <4064721A.6060905@tat.physik.uni-tuebingen.de> References: <20040324170719.A12420@synopsys.com> <200403261621.i2QGLQ7X014994@speedy.slc.redhat.com> <20040326094202.A2838@synopsys.com> <1080323297.4600.160.camel@localhost.localdomain> <4064721A.6060905@tat.physik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D963904-7F52-11D8-8E0B-000A95BA54A6@apple.com> Content-Transfer-Encoding: 7bit Cc: Joe Buck , Jeff Law , "gcc@gcc.gnu.org" , Diego Novillo From: Fariborz Jahanian Subject: Re: -ffast-math and floating point reordering Date: Fri, 26 Mar 2004 19:54:00 -0000 To: Richard Guenther X-SW-Source: 2004-03/txt/msg01569.txt.bz2 On Mar 26, 2004, at 10:10 AM, Richard Guenther wrote: > 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. Yes. Also 'generic' must include an PAREN_EXPR, or ORD_EXPR that languages can take advantage of and rest of the compiler honor. - Fariborz > > Richard.