Re: [tree-ssa] Maintaining/representing def-use/use-def information

[law at redhat dot com]

In message <Pine.LNX.4.44.0312151502130.27073-100000@nondot.org>, Chris Lattner
 writes:
 >On 15 Dec 2003, Andrew MacLeod wrote:
 >> On Mon, 2003-12-15 at 15:06, Chris Lattner wrote:
 >> > What you are saying is that instead of _one_ memory allocation to
 >> > represent a logical operation, you are uisng 4 (VAR_DECL, SSA_NAME, "2",
 >> > MODIFY_EXPR).  Even if some of these are shared, doesn't this make
 >> > traversing the representation really expensive and cache unfriendly.  You
 >> > also didn't show how a variable is referenced as an operand.
 >
 >> The number of memory allocations isnt the point when we are talking
 >> about how well integrated something is. the VAR_DECL, SSA_NAME. "2",
 >> MODIFY *could* be implemented as a single allcoation if we so chose, but
 >> it wouldnt take much less memory, and it wouldnt make anything else
 >> better or easier. We still need all the information in those various
 >> nodes.  There is a minor amount of duplication (ie, MODIFY and VAR_DECL
 >> both have types), but thats not where we have siginificant memory
 >> lossage. SSA_NAMES themselves are fairly efficient and only exist once.
 >
 >Ok.  I was just trying to point out a deficiency in your system that I
 >perceived.  If you don't agree, then I certainly will not try to force the
 >point.  I'm just trying to point out stuff that might become a problem
 >down the line as early as possible, as opposed to letting you discover the
 >problem later when it may be harder to recover.  I'm truly not trying to
 >start a pointless flamewar. :)
And just so it's clear, it is appreciated, even if sometimes we argue or
don't take your advice, it is definitely appreciated.

 >> How do you deal with a stmt which has more than once DEF?  We have
 >> precious few, but they do exist.
 >
 >We don't.  They don't exist in SSA form.  The only feature we have not
 >implemented yet is inline assembly, and for that I plan to use lvalues
 >("by reference parameters") to represent the multiple outputs possible
 >from a single "asm statement". Everything else is fully implemented in
 >LLVM, and we have not had a problem so far.
ASMs are the root of all evil.  Oh wait, that was nested functions :-)



 >> > This is what I mean by integrating SSA as a first-class feature in your
 >> > representation.  How would this be represented in tree-ssa?
 >>
 >> a_2 = 1 + 2
 >> a_3 = a_2 + a_2
 >>
 >> we have 2 SSA_NAMES, allocated once.
 >>
 >>    SSA_NAME   and     SSA_NAME
 >>     /    \             /   \
 >>    a      3           a     2
 >>
 >> both of which could have been a single allocation if we chose, but it
 >> turns out to be less memory to allocate them as SSA_NAMEs as Diego has
 >> already pointed out.
 >
 >So, you're saying that it's better than using VAR_DECL's directly, which,
 >of course, carry a lot of baggage that you're not interested in.  Why use
 >them at all?
They're interesting when they refer to user variables from a debugging
standpoint.  I don't think they're particularly interesting when they
refer to expression temporaries.

More than once I've thought about what it would take to simply not have
_DECL nodes for expression temporaries.  I just haven't see a clean way
to make them go away within our current framework.

Andrew's recent work in operand walking actually makes it easier to do
some of this kind of stuff -- though we're certainly a long way from
being able to make that happen.

I would seriously consider banning stuff like TREE_OPERAND and TREE_CODE
(and instead expanding upon Andrew's framework) from the SSA optimizers
once we've past the first milestone of getting integrated into the mainline
tree.  But it's something I don't think we want to tackle right now.

jeff