This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] variables being dragged out of their lexical scopes
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 1 May 2003 12:07:42 -0400
- Subject: Re: [tree-ssa] variables being dragged out of their lexical scopes
On Thursday, May 1, 2003, at 10:24 AM, Diego Novillo wrote:
Given this program:
foo ()
{
int i, k;
{
int j;
j = i + 1;
}
k = i + 1;
return i;
}
the conversion into SSA form is currently converting it into:
foo ()
{
int i;
int k;
# BLOCK 0 (a.c:6). PRED: -1. SUCC: -2.
{
int j;
j_2 = i_1 + 1
};
k_3 = j_2;
return i_1;
}
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).
How so?
Jason suggested that we could create additional temporaries in
the gimplifier so that we always convert assignments 'VAR = EXPR'
into 'TEMP = EXPR; VAR = TEMP':
Ugh.
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.
Double ughh.
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).
Triple uggh.
I *really* don't want code movement optimization to have to start
dealing with clobbers like that for regular variables.
Thoughts?
Can't we fix the debuggability problem?
We aren't going to be *optimizing* at -O0, and at -O2, debugability
takes a back seat.
So i don't understand how any copy-prop argument is valid at -O0, since
we aren't going to be *running* copy-prop at -O0.
Diego.