From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22641 invoked by alias); 13 May 2003 13:11:40 -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 22531 invoked from network); 13 May 2003 13:11:39 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 13 May 2003 13:11:39 -0000 Received: from localhost (tornado.toronto.redhat.com [172.16.14.228]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 9D60C8000E1; Tue, 13 May 2003 09:11:38 -0400 (EDT) Subject: Re: [tree-ssa] Out of SSA status and issues From: Diego Novillo To: Michael Matz Cc: Andrew Macleod , gcc mailing list In-Reply-To: References: Content-Type: text/plain Organization: Red Hat Canada Message-Id: <1052831496.27232.247.camel@frodo.toronto.redhat.com> Mime-Version: 1.0 Date: Tue, 13 May 2003 13:11:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg01295.txt.bz2 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. > 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. Diego.