Re: SSA question

[Chris Lattner <sabre at nondot dot org>]

> writes:
>  > I'm wondering why the first set gets generated to refer to its own value
>  > (it seems that PHI nodes should be the only insn's that should do that).
>  > The instruction coming into SSA constructure looks like this [which is
>  > identical to the above insn]:
> Because insn 13 is the only definition site for reg 107.  During the
> renaming process we avoid renaming the first definition site as it
> isn't necessary.

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

>  > Would it be better to mark undefined incoming
>  > values as being used already so that they are renamed and distinct?
> 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].

> What are you really trying to accomplish?

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.

Is there something I'm missing here?  Is there an easy way to see that the
incoming value is undefined?

Thanks for the help!

-Chris

http://www.nondot.org/~sabre/os/
http://www.nondot.org/MagicStats/