From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-93484-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17096 invoked by alias); 26 Mar 2004 17:48:31 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 17049 invoked from network); 26 Mar 2004 17:48:30 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sources.redhat.com with SMTP; 26 Mar 2004 17:48:30 -0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i2QHmT1X009009;
	Fri, 26 Mar 2004 12:48:29 -0500
Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i2QHmTj18092;
	Fri, 26 Mar 2004 12:48:29 -0500
Received: from [10.0.0.106] (dnovillo.cipe.redhat.com [10.0.0.106])
	by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i2QHmRf7019375;
	Fri, 26 Mar 2004 12:48:27 -0500
Subject: Re: -ffast-math and floating point reordering
From: Diego Novillo <dnovillo@redhat.com>
To: Joe Buck <Joe.Buck@synopsys.com>
Cc: Jeff Law <law@redhat.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
In-Reply-To: <20040326094202.A2838@synopsys.com>
References: <20040324170719.A12420@synopsys.com>
	 <200403261621.i2QGLQ7X014994@speedy.slc.redhat.com>
	 <20040326094202.A2838@synopsys.com>
Content-Type: text/plain
Organization: Red Hat Canada
Message-Id: <1080323297.4600.160.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Fri, 26 Mar 2004 18:46:00 -0000
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-03/txt/msg01565.txt.bz2

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.


Diego.