From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32204 invoked by alias); 13 May 2003 15:01: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 32186 invoked from network); 13 May 2003 15:01:29 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 13 May 2003 15:01:29 -0000 Received: from [192.168.1.3] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b6) with ESMTP-TLS id 3954657; Tue, 13 May 2003 11:01:15 -0400 Date: Tue, 13 May 2003 15:01:00 -0000 Subject: Re: [tree-ssa] Out of SSA status and issues Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Diego Novillo , Andrew Macleod , gcc mailing list To: Michael Matz From: Daniel Berlin In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg01311.txt.bz2 On Tuesday, May 13, 2003, at 08:56 AM, 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 useful > thing of > SSA is, that there is exactly one definition of an entity, and that is > the > reason that you can copy-propagate extremely easily (because you know, > that the source of the copy can't be possibly changed after that copy > insn, because the def must have reached it, and that was the only def). > > To be able to propagate *p you have to explicitely proove by some means > that it still is unchanged at the places of the uses of the copied-into > entity. This would be exactly detrimental to the usefullness of copy > propagation. > > I.e. *p is not a register but an expression, and a copy instruction > copies > registers to registers. > It would also ruin sparse register promotion that load PRE will do soon, by unpromoting things. >> 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's SSUSPRE (Static Single Use Store PRE). Store PRE builds a single static use form, ... > > Ciao, > Michael. >