This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] BIND_EXPR removal

On Sun, 2 Nov 2003 11:49:29 -0800, Richard Henderson <> wrote:

> On Sun, Nov 02, 2003 at 12:29:12PM +0100, Zdenek Dvorak wrote:
>> OK, the second attempt.  It just records the variables in the gimple
>> lowering phase, then expands those of them that were not optimized
>> out afterwards (the code to determine this is taken from
>> remove_unused_... in tree-cfg.c, so it should do exactly what we do now).
> This seems ok for now.
> About the only thing I'd change is to *not* keep the outermost
> BIND_EXPR of the function, as you do.  As far as I can tell, the
> only difference this would make is that gimple_add_tmp_var would
> add the variable to your list instead of either queue it in
> gimplify_ctxp->temps or add it to that now missing bind_expr.

Hmm, I was just about to say the opposite--that we should be moving all the
variables to the outer BIND_EXPR rather than to some random global
variable.  Of course, to do that we'd need to support a TREE_LIST for
BIND_EXPR_VARS, but that shouldn't be difficult.

> For the to-look-at-eventually list:
> I've been wondering if we might be able to get better results
> wrt aggregates if we associated basic blocks with scopes, and
> constrained cfg operations to preserve that invariant.  We might
> be able to do reasoning such as noticing that 
> 	void f ()
> 	{
> 	  {
> 	    int x[100];
> 	    g(x);
> 	  }
> 	  h ();
> 	}
> We may tail-call to H because while we did leak local stack for
> X into the global memory pool, it is no longer in scope, and so
> a conforming program could not still access it.

Perhaps we could express this by inserting a new statement to express that
X is dead?  There are certainly other optimizations which could benefit
from knowing that they don't have to worry about some variables.  This
could also apply to dynamically freed/destroyed objects, not just objects
which have gone out of scope.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]