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

[Andrew MacLeod <amacleod at redhat dot com>]

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

3 - instead of copy the var from a temp everywhere, I think we ought to
simply copy the local variable into a temp when the variable goes out of
scope.

So in our simple case:

foo ()
{
  int i;
  int k;
  int T.1;


  # BLOCK 0 (a.c:6).  PRED: -1.  SUCC: -2.
  {
    int j;

    j_2 = i_1 + 1;
    T.1_5 = j_2;
  };
  k_3 = T.1_5;
  return i_1;
}

In order to prevent eventual potential propagation of j_2 outside its
lexical scope, we need a mechanism to prevent that, such as clobbering.
I don't like an explicit clobber expression, like  CLOBBER <j_2> 

How do we prevent propagation of values when, say, an address is taken?

j_2 = i_1 + 1;
call (&j_2);
t_3 = i_1 + 1;

we clearly don't change it to:
j_2 = i_1 + 1;
call (&j_2);
t_3 = j_2;

so we are "clobbering" j_2 at the call location to prevent movement.
Can't we do a similar thing at the copy location?

My guess is that the clobbering information is virtual operands, and
therefore get_stmt_operands() needs to be able to reproduce the virtual
operands without any context. In the case of the call, it knows it needs
to clobber j_2. This wouldnt be clear from just a copy.

So you could have a clobbering copy, but then you have a different tree
opcode to worry about. Maybe thats not so bad. You never want to
propagate the uses from it into other things, so we dont need to special
check for this "other" kind of modify_expr in existing places, and the
only other thing we care about is deleting it if it is dead, which DCE
is going to do regardless of the opcode.

Maybe a clobbering copy (ie, MODIFY_AND_CLOBBER_EXPR) would solve the
problem of preventing j_2 from escaping it's scope.

Andrew