From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3299 invoked by alias); 15 Dec 2003 19:05:01 -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 3290 invoked from network); 15 Dec 2003 19:04:59 -0000 Received: from unknown (HELO mx2.redhat.com) (66.187.237.31) by sources.redhat.com with SMTP; 15 Dec 2003 19:04:59 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id hBFIidA25276; Mon, 15 Dec 2003 13:44:39 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hBFJ4uP22522; Mon, 15 Dec 2003 14:04:56 -0500 Received: from p4 (vpn50-11.rdu.redhat.com [172.16.50.11]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hBFJ4mO24907; Mon, 15 Dec 2003 11:04:49 -0800 Subject: Re: [tree-ssa] Lazy updating of stmt operands From: Andrew MacLeod To: Zdenek Dvorak Cc: Jeff Law , Diego Novillo , gcc mailing list In-Reply-To: <20031211223056.GA20061@atrey.karlin.mff.cuni.cz> References: <1070818186.7334.30.camel@frodo.toronto.redhat.com> <200312111936.hBBJabGj024859@speedy.slc.redhat.com> <20031211223056.GA20061@atrey.karlin.mff.cuni.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 15 Dec 2003 19:10:00 -0000 Message-Id: <1071515090.3354.1681.camel@p4> Mime-Version: 1.0 X-SW-Source: 2003-12/txt/msg00801.txt.bz2 On Thu, 2003-12-11 at 17:30, Zdenek Dvorak wrote: > Hello, > > > >> > tree-dfa.c:compute_immediate_uses() > > >> > > >> Which needs to pass through every single statement in the program. Not > > >> really terribly efficient. > > >> > > >*shrug*, it's used by SSA-CCP. Since def-use edges are only needed by > > >some passes, I don't think it would be worth our while trying to > > >maintain them in get_stmt_operands. > here is the patch. It increases time for compiling preprocessed gcc > sources from 3m43.734s to 3m47.967s. It does not use interface of > immediate uses, since that is not well suited for updating; instead it > just keeps lists of uses for each ssa name. The old interface and ccp > that uses it are not changed by the patch, so in fact the cost would > be a bit smaller. Why isn't it well suited for updating? The information is in the defining stmt's annotation, so given any SSA variable, you can get to the immediate uses by looking at the annotation for SSA_NAME_DEF_STMT. It needs a marginal extention to deal with the fact that there can be multiple defs/vdefs on one stmt, but we need to do that to handle virtual defs anyway. I would prefer to keep this information right with the stmt rather than in a table on the side. Diego, default defs have a (void *)0 stmt, but we can still attach a stmt annotation to them right? (ie, they arent shared) We need to be able to, so you better say yes :-) > > It turned out to be simpler not to require the immediate uses to be > updated all the time; just to keep the list of statements that were > modified and to update it when get_stmt_operands is called. > Indeed, I think we *have* to maintain some laziness about the way stmts are updated. Otherwise if you copy the use of a variable and change it to a new ssa version before you copy/create the feeding defintion, its hard to get it right. The tricky part is undoing what the stmt use to do when its been modified. We have the operand cache, but it points at what *use* to be in the stmt, and that may have potentially been free'd and re-alloced, or reused for something else. There are many places where we simply change the operand and mark the stmt as modified. We can fix that by extending the information slightly in the data flow structure to include a reference to what ssa name the data relates to, but thats reasonably trivial. I'll think about it over the holidays, it should be possible to provide lazy updates of the information for whatever variables are present without too much trouble. It should tie in nicely with the new operands work Ive been doing. > The cost is not insignificant, so we probably don't want to do this > unless I am able to cut it down or we really need it. You will find it much cheaper if you only include the specific variables you are interested in, as CCP does. Andrew