From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4464 invoked by alias); 13 May 2003 13:18:29 -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 4381 invoked from network); 13 May 2003 13:18:29 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 13 May 2003 13:18:29 -0000 Received: from localhost.localdomain (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 656C7800030; Tue, 13 May 2003 09:18:28 -0400 (EDT) Subject: Re: [tree-ssa] Out of SSA status and issues From: Andrew MacLeod To: Diego Novillo Cc: Michael Matz , gcc mailing list In-Reply-To: <1052831496.27232.247.camel@frodo.toronto.redhat.com> References: <1052831496.27232.247.camel@frodo.toronto.redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 13 May 2003 13:18:00 -0000 Message-Id: <1052831908.8201.96.camel@p4> Mime-Version: 1.0 X-SW-Source: 2003-05/txt/msg01297.txt.bz2 On Tue, 2003-05-13 at 09:11, Diego Novillo wrote: > On Tue, 2003-05-13 at 08:56, Michael Matz wrote: > > Hi, > > > > On 13 May 2003, Diego Novillo wrote: > > > > > Why? > > > > > > 1. foo() > > > 2. { > > > 3. int i, *p; > > > 4. > > > 5. p = malloc(); > > > 6. i = *p; > > > 7. return i + 9; > > > 8. } > > > > > > I see nothing wrong in replacing 'i + 9' with '*p + 9'. > > > > I do. *p could have been changed in between 6 and 7. > > > The above is a complete program, *p has not changed between 6 and 7 nor > it is volatile. > but you are missing the point. There are lots of trivial examples which dont show problems. The problem occurs when yoiu add a new stmt, 6.5 *p = 10 copyprop still thinks it can propagate the stmt, but it can't. *p = 10 is not a co[py. It is a store to memory, and you have to go looking at aliasing and such in order to move around loads. copy prop doesnt do that. > > I.e. *p is not a register but an expression, and a copy instruction copies > > registers to registers. > > > Not in tree-ssa. INDIRECT_REFs are first-class variables. Since in > GIMPLE pointers can only be one level deep, we can maintain SSA version > numbers for the pointer and the pointed-to memory location. Granted, it > is somewhat painful (see my other message in this thread) and I'm > starting to think that it may not be sufficiently worth the pain. > > > > Not that tree-ssa will do anything with this code, the default > > > type-based aliasing is too conservative, but PTA may disambiguate this. > > > > Of course you _can_ optimize such cases, but it's not a subset of copy > > propagation but, hmm, un-PRE or something like that. > > > It is if INDIRECT_REFs are treated as regular variables, like we > currently do. I agree that otherwise you need to treat them as > expressions. If we stopped dealing with INDIRECT_REFs as first-class > variables, we would probably move this in to the hands of SSAPRE. > I think the only issue is that the copy prop pass is incorrectly assuming that a load from memory through a pointer is the same thing as a copy between variables, and it isn't. Andrew