[tree-ssa] Lazy updating of stmt operands
Chris Lattner
sabre@nondot.org
Fri Dec 12 19:57:00 GMT 2003
> > 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/
More information about the Gcc
mailing list