From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25965 invoked by alias); 17 Dec 2003 03:30:31 -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 25928 invoked from network); 17 Dec 2003 03:30:30 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 17 Dec 2003 03:30:30 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hBH3USX05300; Tue, 16 Dec 2003 22:30:28 -0500 Received: from speedy.slc.redhat.com (vpn50-19.rdu.redhat.com [172.16.50.19]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBH3URi07835; Tue, 16 Dec 2003 22:30:27 -0500 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.10/8.12.8/Submit) with ESMTP id hBH3TuCB001724; Tue, 16 Dec 2003 20:29:56 -0700 Message-Id: <200312170329.hBH3TuCB001724@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: Zdenek Dvorak cc: Andrew MacLeod , Diego Novillo , gcc mailing list Reply-To: law@redhat.com Subject: Re: [tree-ssa] Lazy updating of stmt operands In-Reply-To: Your message of "Mon, 15 Dec 2003 22:47:27 +0100." <20031215214727.GA31524@atrey.karlin.mff.cuni.cz> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Dec 2003 04:56:00 -0000 X-SW-Source: 2003-12/txt/msg00992.txt.bz2 In message <20031215214727.GA31524@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri tes: >Hello, > >> > > something like >> > > bool immediate_uses_avail_p (tree ssa_name) >> > > or >> > > bool immediate_uses_avail_p (tree stmt) >> > > >> > > Presumably the latter, but both are easy to provide. >> > >> > ??? I don't really quite get you. Either the information should be >> > available for every statement or not at all. Having something in the >> > middle is just confusing. >> > >> >> I dont see why. If you want to track just a few variables, why should >> you pay for tracking 45,000? > >because you generally don't know which variables you are interested in. But sometimes you do (for example CCP) and not computing it for all those variables you don't care about is a significant win. >Also chosing the different ones in the different passes requieres >recomputing the information, and it is not at all obvious to me whether >this would not make this actually more expensive. True. There's now way to know for sure until you actually try it. However, our experience so far has been that "pruning" the set of things we're computing (whether they're immediate uses, variables which might need PHIs, etc) has been very advantageous from both a compile time standpoint and a runtime standpoint. Jeff