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

[Andrew MacLeod <amacleod@redhat.com>]

On Thu, 2003-12-11 at 22:43, Chris Lattner wrote:
> On Thu, 11 Dec 2003 law@redhat.com wrote:
> >  >Jeff Law wrote:
> >  >> While it's nice to think about a world where you always have immediate
> >  >> uses, you end up with FUD chains if you do that -- with ultimately a
> >  >> tangled nest of pointers that is bloody impossible to work with in the
> >  >> real world.
> >  >
> >  >Uh, no.  Here's a counter-example:
> >  > http://llvm.cs.uiuc.edu/
> >  >
> >  >Having efficient, transparently & efficiently updated immediate use
> >  >information is extremely valuable for a wide variety of optimizations.
> > OK.  Maybe it was just Diego implementation that was an unmaintainable
> > mess :-)
> 
> 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.  

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

I suspect the loop optimizations are going to fall into the same
category as CCP in that they are going to be interested in the immediate
uses of only a partial subset of variables most of the time. I think its
far more efficient to calculate those when you need them/know what they
are, and possibly maintain just those def->uses.

Andrew