From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4709 invoked by alias); 22 Oct 2004 21:08:44 -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 4688 invoked from network); 22 Oct 2004 21:08:43 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sourceware.org with SMTP; 22 Oct 2004 21:08:43 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 29025) id 052F24B40F7; Fri, 22 Oct 2004 23:08:41 +0200 (CEST) Date: Fri, 22 Oct 2004 21:33:00 -0000 From: Zdenek Dvorak To: Andrew MacLeod Cc: Michael Matz , gcc-patches Subject: Re: [ssaupdate] Local dominance info Message-ID: <20041022210841.GB1486@atrey.karlin.mff.cuni.cz> References: <20041019215129.GA29721@atrey.karlin.mff.cuni.cz> <1098279112.5695.3918.camel@pain> <20041020192719.GA20919@atrey.karlin.mff.cuni.cz> <1098310966.20227.24.camel@pain> <1098463105.20227.52.camel@pain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1098463105.20227.52.camel@pain> User-Agent: Mutt/1.5.6i X-SW-Source: 2004-10/txt/msg01963.txt.bz2 Hello, > the claim is that it is cheap. I claim it will have a cost, perhaps it > is small most of the time, but there is bound to be pathological cases > which do have an impact. > > > > I don't see any reason why it should be kept up to date all the time > > > when virtually no-one else cares about it. > > > > Cleanlyness of interfaces? Less potential for funny bugs because the > > wrong inserters were used by some common code? > > It depends. I've seen no reason for it. If it turns out that having it > present *will* make a different in updating ssa on the fly, thats > different. I've seen no argument why 70 other optimizations should keep > the information up to date when they dont care about it. > > The general renamer has to go through all the basic blocks *anyway* in > order to calculate live-on-entry, so it seems pretty easy to do that > local numbering on the fly since you are making a pass the the IL > anyway. > > If there is a more iterative into-ssa solution that can make use of this > info and doesnt have to make a pass through the IL, then thats an > arguement for it. If there is a reason to keep it up to date other than > that, perhaps that is an argument too. > > So far all Ive seen/heard is keeping the information up to date doesnt > cost a lot, but I see few passes have a use for it. Tell me how useful > it is, and why its better than calculating it on the fly when you need > it and maybe I am convinced. answer to your questions from my side is "I don't know." I think it will be useful (obviously :-), but it may turn out that I will be wrong. Ssaupdate is a development branch, so the way things are done now do not necessarily have to be the same (or even close to) those that will be in final version. Zdenek