From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 459 invoked by alias); 15 Dec 2003 22:25:05 -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 435 invoked from network); 15 Dec 2003 22:25:03 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Dec 2003 22:25:03 -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 hBFMP1h27967; Mon, 15 Dec 2003 17:25:01 -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 hBFMP0n04270; Mon, 15 Dec 2003 17:25:00 -0500 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.10/8.12.8/Submit) with ESMTP id hBFMOUmv018734; Mon, 15 Dec 2003 15:24:31 -0700 Message-Id: <200312152224.hBFMOUmv018734@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: Andrew MacLeod cc: Zdenek Dvorak , 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 "15 Dec 2003 17:03:46 EST." <1071525828.3257.1907.camel@p4> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 2003 22:39:00 -0000 X-SW-Source: 2003-12/txt/msg00853.txt.bz2 In message <1071525828.3257.1907.camel@p4>, Andrew MacLeod writes: >I guess it depends on how hard it is to find out. CCP goes and >determines an initial value for every variable. If the initial value is >something we already know cannot be a constant, we dont include it. THis >was very significant for virtual PHI nodes, since that means they never >got included,so we save a lot on those 2000 element phi nodes. Right. >> I am not sure whether this is not saving on the wrong place. You need >> some 12 bytes per operand (perhaps 8, with some extra effort), which >> seems incomparable to the amount of memory we waste everywhere else. > >It may be suprising, but you end up with PHIs which have 2000 operands, >and they reach 40 different places.. it does both consume a reasonable >amount of memory, and it takes measurable amounts of time to build the >additional information. > >To take a step back, this was quite a while ago before we did some of >our recent wonderful memory work. I will look at it again, and see if >its still nasty. You can give it a quick try yourself. the function > need_imm_uses_for >in tree-ssa-ccp, change it to return true all the time, and see what the >compilation time difference for gerald testcase is. It use to increase >CCPs time as well as overall time noticably. Perhaps it doesn't now, I >havent tried it lately. I doubt Zdenek will see a huge change -- largely because we factor the computed gotos which were causing the PHI explosions. But the underlying concept of filtering out variables we do not care about (because we know they are varying) is still wise. And to a much lesser extent, part of the problem is that we create way too many virtual operands because of our lousy aliasing. jeff