Re: [tree-ssa] Fix variables getting out of their scope

[law at redhat dot com]

In message <20030820195544.GA13913@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
 >Hello,
 >
 >> >>Not really -- not every BIND_EXPR has a BIND_EXPR_BLOCK.
 >> >>
 >> >Ah, yes.  In that case the patch is OK.
 >> >
 >> 
 >> Actually, Zdenek, if it's not too much trouble, could you update 
 >> bsi_move_* to make it reset the scope on the moved statement to the 
 >> proper new scope?
 >> That way when you move a statement, you can just call fixup_var_scopes 
 >> on the defined variable with the old scope, and it'll do the right 
 >> thing.
 >
 >this (untested) should make what you want.  On the other hand, I
 >consider all of this a temporary hack before some better solution
 >what to do with BIND_EXPRs is devised.
 >
 >Some ideas what to do with them?  It would be nice if we could shomehow
 >get rid of them before more radical changes from tree-ssa-cfg are
 >merged, as they bring nothing but problems.
Well, we may not be able to get rid of them right now, but we may be able to
lessen their impact.

I took a couple minutes and poked at one testcase you posted with the
code to remove LOOP_EXPRs.  As much as I pushed to have BIND_EXPRs not
create new basic blocks, I starting to think that they really need to
be treated like other statements such as COND_EXPR, SWITCH_EXPR, etc.

The problem your testcase exposes with BIND_EXPRs are directly related
to the fact that we try to hide them and avoid creating new basic blocks
for them.

void foo(void)
{
  if (1)
    {
      goto bla;
    }
  else
    {
xxx:
	{
bla:
	  bar ();
	  return;
	}
      goto xxx;
    }
}


We need to keep the BIND_EXPR after "xxx" because it has reachable
code inside it.  And since BIND_EXPRs don't start/end basic blocks
and don't appear as statements when using the block statement iterators, 
we don't have a clean way to find BIND_EXPRs to see if they contain
any reachable code.

Ugh.

I also believe that the second test suffers from the fact that 
BIND_EXPRs are totally hidden.

So in the short term it may make sense to stop hiding BIND_EXPRs
and go ahead and create new blocks for them.  That should make our
compiler more robust in response to unstructured code and make
it handle removal of LOOP_EXPRs a little more sanely since that
seems to introduce more unstructured flow control.

Of course I want to see BIND_EXPRs go away along with the other
control structures, but I don't want to see removal of LOOP_EXPRs
be dependent on removal of BIND_EXPRs.

Thoughts?
jeff