Re: [tree-ssa]: Easy way to get default def of a variable?

[Andrew MacLeod <amacleod at redhat dot com>]

On Wed, 2003-06-04 at 23:46, Diego Novillo wrote:
> On Wed, 2003-06-04 at 23:14, Andrew MacLeod wrote:
> 
> > ??  You mean to artificially provide the "first" def?
> > 
> > As Ive stated to Diego on a few occasions, Im uncomfortable with the
> > whole concept of a use without a def, as all these live on entry
> > variables are.  Seeing a use of a variable with a matching def seems
                                               ^^^^
                                               without
> > wrong.
> > 
> Hmm, every variable has a matching def.  If an SSA name has
> empty_stmt_expr as its defining statement then it is either (1) a local
> variable used uninitialized or (2) a function argument that's live on
> entry.
> 

And its a *big* difference which it is. Being able to determine it
easily is useful.

> > Maybe we ought to have something for these DEFs to point to. I kinda
> > like the idea of a table of "defs" which each live on entry variable
> > points to as its def. Something like that anyway. At least it doesn't
> > pollute the instruction space.
> > 
> We now connect them to empty_stmt_expr.  Do you want to connect them to
> this table so that we can traverse that table to look for live-on-entry
> or uninitialized uses?  I guess we could do that.
> 
> 
They are connected to an empty_stmt_node which is just hung out in space
somewhere? Unfortunately, sticking those ina  table isn't going to tell
you *where* or *who* the use of the empty_stmt_node is.. Unless you made
the table pairs  {SSA_NAME, empty_stmt_node}. Then you could quickly
traverse the table, see all the SSA_NAMES, and know what you are looking
at. 

Then again, what does it buy you to put the empty_stmt_node in the
table.. not a heck of a lot eh.

I guess all we really need is a chained list of variables which are live
on entry.  And of course, anyone neededing that information ought to be
able to make 1 pass through the IL and determine it as well... 

And if someone does cause a new uninitialized variable, it wouldn't be
in this list, and is that going to cause Dan difficulty? ie, is he going
to need a quick pass through to find out whats *currently*
uninitialized?   maybe it doesn't matter

> > It would let us catch things in the out of ssa pass which accidentally
> > have no def, much like assign_vars use to do...  
> > 
> We can do this already without that table you mentioned.  I'm missing
> something here.

By going and looking at the storage class of the variable you mean?  I
think I'd prefer something a little more formal than that personally...
It seems like somthing the into-ssa can generate with no thought, and
hang off the function node or something, then we have a record of what
is *suppose* to be live on entry.  Say, Isn't it possible for locals to
be live on entry to a nested function? meaning the storage class won't
tell you whether its right or not.

Its early, Im rambling on :-)
Andrew