From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21924 invoked by alias); 20 Oct 2004 13:32:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 21917 invoked from network); 20 Oct 2004 13:32:01 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 20 Oct 2004 13:32:01 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i9KDVvsv022040; Wed, 20 Oct 2004 09:31:57 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9KDVur25455; Wed, 20 Oct 2004 09:31:56 -0400 Received: from pain (vpn50-35.rdu.redhat.com [172.16.50.35]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id i9KDVrvn029745; Wed, 20 Oct 2004 09:31:54 -0400 Subject: Re: [ssaupdate] Local dominance info From: Andrew MacLeod To: Zdenek Dvorak Cc: gcc-patches In-Reply-To: <20041019215129.GA29721@atrey.karlin.mff.cuni.cz> References: <20041019215129.GA29721@atrey.karlin.mff.cuni.cz> Content-Type: text/plain Message-Id: <1098279112.5695.3918.camel@pain> Mime-Version: 1.0 Date: Wed, 20 Oct 2004 13:32:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg01721.txt.bz2 On Tue, 2004-10-19 at 17:51, Zdenek Dvorak wrote: > Hello, > > this patch adds dominance information to statements, i.e. it makes it > possible to decide whether a statement precedes other one inside a basic > block without need to scan the whole block. > > To enable this, statements inside basic block are numbered (the > numbering contains holes, so that new statements may be inserted). This > seems to work good enough (no measurable impact on compile time). You want to keep and maintain this information all the time? This strikes me *much* more as a local thing that an individual pass might be interested in, and so should number the stmt's itself for the duration of its interest. I think trying to keep numbered order of stmts within blocks for the duration of SSA is a very bad idea since most optimizations do not care. So you have the overhead of making sure that you keep things kosher everytime you ever move anything. You will always have an end case where the hole isnt big enough, so you'll have to renumber either the entire block, or parts of it. This will no doubt happen during an optimization phase that doesn't care about local numbers. I can see having an aux field in stmts much like edges do, where an individual pass can use that field for whatever it want, in your case for these local dominance numbers. If you wish to maintain these numbers for a series of optimizations and you are interested in having the insert routines take care of it for you, then at best I could see creating local_dom_insert_before(), local_dom_insert_after(), etc which call the bsi_* insertion routines, and then update your local dominance info. Then you could use those routine in areas where you care about it without affecting anyone else. This seems like it ought to be pretty easy to do since you call setup_local_dom_number() as the last thing after inserting. I do not thing this should be part of the generic bsi_* routines. Andrew