Re: SSA question

[law at redhat dot com]

 In message <Pine.LNX.4.30.0203141146430.6260-100000@nondot.org>, Chris 
Lattner
writes:
 > Ok, I see where this is happening (ssa.c):
 > ...
 > 	  /* Else this is a use before a set.  Warn?  */
 > 
 > >  > Is this desirable behavior?
 > > It's marginally interesting.  Though it may not play well with GVN/GCM
 > > schemes such as from Click's paper in PLDI 95.
 > 
 > Ok, if it's desired behavior, that's fine.  :)
I wouldn't go so far as to call it desirable :-)  Just interesting.  It
wouldn't be that hard to convince me to rename it.

 > > There's little value in marking it undefined as it's obviously undefined
 > > when you look at the SSA graph.
 > 
 > But that's not true... because in this case, it _is_ defined by the
 > add instruction itself [at least according to the SSA graph].
A self-reference in SSA form like that clearly shows that the value is
undefined.  Hmmm, maybe we're using different interpretations of
defined and undefined.  I probably should have said the _value_ is
undefined to be clearer.


 > I'm trying to do some analysis on the SSA graph and am coming to the false
 > conclusion that the input to the add is defined (it has an SSA
 > definition), but the problem is that its definition does not dominate its
 > use like all other ssa values.
OK.    So let's consider

foo()
{
  int a,b,c;

  a = b + c;
  b = 5;
  c = 9;
}


Looking at this variant, for the problem you're trying to solve, would
seem to argue that we should either rename as you've suggested or do
something (I'm not precisely sure what) to indicate that at the assignment
to "a" that "b" and "c" are undefined and thus "a" has an undefined value.
And I don't see any trivial way to make this determination with the SSA
graph as it exists right now in GCC.

By renaming as you've suggested we could look up the definition of b and get
null because the assignment to be was renamed.

Go ahead and cobble up a patch, I'll review it.

jeff