Re: [tree-ssa] Lazy updating of stmt operands

[Chris Lattner <sabre at nondot dot org>]

> > 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/