[tree-ssa] variables being dragged out of their lexical scopes

[law@redhat.com]

In message <20030501142431.GB18264@tornado.toronto.redhat.com>, Diego Novillo 
writes:
 >Notice how j_2 is now used outside of its original lexical scope.
 >Apparently, this is a problem because moving variables outside
 >their scope affects debuggability (and maybe it has other side
 >effects?  I don't know).
It also makes it exceedingly difficult for me to go around zapping
unnecessary BIND_EXPRs, which we seem to create annoyingly too often.

ie, if a BIND_EXPR has no executable code, then frankly it just needs to
go away completely -- not only do you avoid expanding the BIND_EXPR, you
avoid expanding all those silly unused variables which we're all to happy
to create as well.

This is both compile time and runtime issue.  The former because
expanding useless BIND_EXPRs and variables is, well, a waste of time.
The latter because an unused variable which is addressable will still
have stack space created for it.  If we zap the BIND_EXPR, then
we don't have to worry about silly BIND_EXPR and VAR_EXPR expansion
or creating stack space for unused variables.



 >Jason suggested that we could create additional temporaries in
 >the gimplifier so that we always convert assignments 'VAR = EXPR'
 >into 'TEMP = EXPR; VAR = TEMP':
My biggest concern with this is that it would involve creating many
more temporaries -- that is unless we get to a point where we're
using a formal temporary table/hashed ssa.  In which case we're
probably still creating more variables than we need, but the
affects won't be as noticable.

[ ... ]

 >I see two ways of handling this:
 >
 >1- Never allow copy propagation in expressions of the form 'VAR = TEMP'
 >   (where 'VAR' is a program variable and 'TEMP' a compiler
 >   temporary).  This could work but I'm not sure if it would be a
 >   valid long term approach.
Doesn't seem wise to me.

 >
 >2- While building the flowgraph, emit a group-clobber instruction
 >   for all the variables that were declared inside a lexical
 >   scope.  The clobber instruction would be a new GIMPLE
 >   statement of the form CLOBBER_EXPR <var1, var2, ..., varN>.
 >   This would avoid any code movement that tries to take
 >   variables outside of their original scope (and it would also
 >   avoid having to generate all those temporaries in the
 >   gimplifier).
This seems like it might be viable.  Especially if combined with
Jason's suggestion.  You get the optimizations we want, but 
without the problems with using variables outside their defined
scope.

jeff