From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9437 invoked by alias); 12 Dec 2003 19:55:53 -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 9373 invoked from network); 12 Dec 2003 19:55:51 -0000 Received: from unknown (HELO nondot.org) (128.174.245.159) by sources.redhat.com with SMTP; 12 Dec 2003 19:55:51 -0000 Received: by nondot.org (Postfix, from userid 501) id 9091B17C035; Fri, 12 Dec 2003 14:57:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by nondot.org (Postfix) with ESMTP id 8D24C24C2AD; Fri, 12 Dec 2003 13:57:31 -0600 (CST) Date: Fri, 12 Dec 2003 19:57:00 -0000 From: Chris Lattner To: Andrew MacLeod Cc: Jeff Law , Zdenek Dvorak , gcc mailing list Subject: Re: [tree-ssa] Lazy updating of stmt operands In-Reply-To: <1071256652.14001.265.camel@p4> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-12/txt/msg00738.txt.bz2 > > I really can't emphasize enough how important this is. For example, this > > information allows an efficient implementation of the LLVM > > Value::replaceAllUsesOf operation (which makes all users of a value use > > something else, think replacing 'add 2, 4' with '6'). The presence of > > this operation makes copy operations in the IR completely superfluous, > > along with "copy-propagation" passes (which either effectively have to be > > run between all transformations, or be built into all of them). This > > simplifies transformations, makes code more maintainable, etc... > > Its not just maintainability that is at issue. Maintaining immediate > uses is not difficult. Memory consumption rises dramatically when you > have a lot ssa names and uses and maintain those links. It was a > Significant memory win to only calculate immediate uses for the > ssa_names we cared about in CCP as opposed to all ssa-names. How much memory consumption are we talking about here? In LLVM, each instruction consumes space for itself (to hold the opcode, type, etc.), and 4 words for each operand. The 4 words includes all use-def and def use information. SSA can be a very light-weight representation. > We already have memory footprint problems, and maintaining def->use > links all the time is going to aggravate that situation even more. If > there are times when it is necessary, it ought not be hard to maintain > that information within our current framework. I see no reason to have > it present all the time when only some consumers need it... If you're trying to work around the problem with caches and recomputation of information, I suspect that you are barking up the wrong tree. That said, I don't know exactly what's going on in the tree-ssa world, so there may be complicating factors. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/