From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-74118-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2923 invoked by alias); 13 May 2003 12:57:32 -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 2887 invoked from network); 13 May 2003 12:57:31 -0000
Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105)
  by sources.redhat.com with SMTP; 13 May 2003 12:57:31 -0000
Received: from localhost (tornado.toronto.redhat.com [172.16.14.228])
	by touchme.toronto.redhat.com (Postfix) with ESMTP
	id 71243800030; Tue, 13 May 2003 08:57:30 -0400 (EDT)
Subject: Re: [tree-ssa] Out of SSA status and issues
From: Diego Novillo <dnovillo@redhat.com>
To: Andrew Macleod <amacleod@redhat.com>
Cc: gcc mailing list <gcc@gcc.gnu.org>
In-Reply-To: <1052830148.3299.80.camel@p4>
References: <1052750563.2730.317.camel@p4>  <1052765152.3372.28.camel@p4>
	 <1052829209.27232.210.camel@frodo.toronto.redhat.com>
	 <1052830148.3299.80.camel@p4>
Content-Type: text/plain
Organization: Red Hat Canada
Message-Id: <1052830648.27232.231.camel@frodo.toronto.redhat.com>
Mime-Version: 1.0
Date: Tue, 13 May 2003 12:58:00 -0000
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-05/txt/msg01292.txt.bz2

On Tue, 2003-05-13 at 08:49, Andrew MacLeod wrote:
> On Tue, 2003-05-13 at 08:33, Diego Novillo wrote:
> > On Mon, 2003-05-12 at 14:45, Andrew MacLeod wrote:
> > 
> > > ie it would look something like this hacked up example:
> > >  
> > >       #   (*T.6)_13 = VDEF <(*T.6)_7>;
> > >       T.6_12 = T.2_8 + T.5_11;
> > > 
> > >       #   VUSE <T.6_12>;
> > >       i_14 = (*T.6)_13
> > > 
> > >       #   (*T.6)_22 = VDEF <(*T.6)_13>      
> > >       #   VUSE <T.6_12>
> > >       *T.6 = 30;
> > >     };
> > >   #   i_1 = PHI <i_6(0), (*T.6)_13(1)>;
> > > 
> > > Or is there a reason that copyprop would never happen?
> > >
> > Correctness wise?  No, there's no reason.  We can safely do the
> > propagation in this case.
> > 
> > But I wouldn't think it's efficient.  Pointer dereferences are bound to
> > be slower than a straight scalar reference.  The copy propagator in the
> > SSA renamer blocks propagation of INDIRECT_REF nodes.  The stand-alone
> > copy propagator should probably do the same.
> > 
> >
> but this code is rewritten into:
> 
>  T.6 = T.2 + T.5
>  i_14 = *T.6
> *T.6 = 30
>  i_1 = *T.6
> 
> Thats not the same meaning at all....
> 
Drat, I hadn't noticed that *T.6 was aliased.  Yes, in this case
copyprop is doing the wrong thing.  It shouldn't be propagating from
VDEFs into PHIs like that.  Sorry about that.

So, is it copyprop or the copy propagator in the SSA rename pass?  I
don't think the SSA renamer would do this because we specifically block
propagating dereferences.


Diego.