[tree-ssa] Thoughts on live-on-entry variables

[Jan Hubicka]

> 
> Recently Dan and Andrew asked about having access to a list of all the
> SSA names that were artificially created by the SSA rename pass for uses
> of variables without a preceding definition.  For instance,
> 
> 	foo (int i)
> 	{
> 	  int a, b;
> 
> 	  if (i > 10)
> 	    b = a + 1;
> 	}
> 
> is renamed to
> 
>      1. foo (int i)
>      2. {
>      3.   int a, b;
>      4.   if (i_1 > 10)
>      5.     b_2 = a_3 + 1;
>      6. }
> 
> In this program, SSA names i_1 and a_3 have appeared out of thin air.
> These "default definitions" were created by the SSA rename pass when it
> found no preceding definition for those loads.  In the case of i_1, this
> indicates that i_1 comes from outside foo().  In the case of a_3, this
> indicates that variable 'a' is being accessed uninitialized.
> 
> The request was to have these SSA names in some list that can be
> referenced when doing various things in PRE and the SSA->normal pass.  I
> would have another use for this, to provide a (hopefully) pretty
> accurate warning about uninitialized variable accesses.

In RTL we keep track of this by having pointer to the original register
(variable) it has been derrived from.  Would this satisfy your needs?
Having both forms compatible will make easier to lower the information
during RTL expansion.
(your de-SSA pass currently deals with this by replacing renamed
variables by the originals, right?)

Honza