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

[Diego Novillo]

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.

At first, I thought that the list should be enough.  It's easy enough
for the SSA renamer to add elements to this list as it goes through the
code.  However, as with anything we have outside of the IL, this list
needs to be kept up-to-date.  Suppose that the statement at line 5 is
removed, all uses of a_3 in that code would have disappeared.  If
anything relies on traversing this list to do its thing, it will get
easily confused.

Right now I'm leaning towards exposing default definitions in the IL by
either creating a new GIMPLE statement like DEFAULT_DEF <SSA_NAME>, or
using MODIFY_EXPR.  This has the double advantage that (a) it's
automatically kept up-to-date by the various optimizers (i.e., dead-code
would naturally remove these definitions if all the uses were removed),
and (b) it can be used by PRE and the SSA->normal pass without
consulting an on-the-side data structure, they're there in the IL.

Also, emitting warnings about uninitialized would now be very easy.  Any
SSA name in the code that can be reached by one of these default
definitions and its variable is not a PARM_DECL, it represents a use of
an uninitialized variable.  This pass would run at the end of the
optimization pipeline, which would minimize (eliminate?) false
positives.

Thoughts?


Diego.