Reusing stack slots

Reusing stack slots

[Daniel Jacobowitz]

On Tue, Jun 29, 2004 at 11:16:52AM -0700, Jim Wilson wrote:
> Ian Lance Taylor wrote:
> >For example, here is a quickie test for whether arrays declared in
> >different blocks overlap.  This test appears to currently always fail.
> 
> See bug #9997 which has a 4 line patch (only two lines of actual code) 
> that fixes this.  It just needs someone to test the patch.  This is in 
> my backlog of stuff to look at some day, but it is probably faster if 
> someone else does it.

I retested this patch.  As you suspected, it no longer causes a
regression.  However, I can't identify the previously problematic
code in alias2.C; tree-ssa generates drastically different code.
The patch no longer affects the code generated for that test.

However, the patch no longer fixes the testcase for PR 9997.  Something
else has broken it since then - preserve_temp_slots is no longer called
with anything but NULL_RTX.  One of the other related problems you've
mentioned is probably to blame.

-- 
Daniel Jacobowitz

Re: Reusing stack slots

[Jim Wilson]

On Sat, 2004-07-03 at 20:11, Daniel Jacobowitz wrote:
> However, the patch no longer fixes the testcase for PR 9997.  Something
> else has broken it since then - preserve_temp_slots is no longer called
> with anything but NULL_RTX.  One of the other related problems you've
> mentioned is probably to blame.

The something else is tree-ssa.  The handling of stack slots for
variables has been changed quite a bit, and we can no longer share space
for locals defined in different blocks.

Before tree-ssa, we were calling push_temp_slots every time we entered a
new scope, and preserve_temp_slots/free_temp_slots/pop_temp_slots when
we exited a scope.  Local variables were allocated in between the
push_temp_slots and preserve_temp_slots calls.  This allowed us to free
space used by variables defined in a scope that we just exited.

After tree-ssa, local variables are not allocated when we see them. 
Instead they are put on unexpanded_var_list.  There is no scoping info
recorded for them.  These variables then all get allocated at the same
time when we , and hence we can not overlap space allocated for any of
them.  The new scheme does have the benefit that we can check to see
whether a variable is used before we allocate it.  It is a shame we lost
the ability to share stack space for them though.

This is not a 4 line fix.  We need to somehow record or replay scoping
info for the variables in unexpanded_var_list, so we can overlap the
space allocated for them when the scopes don't overlap.  We also may
need changes in other places, for instance the aliasing code looks at
unexpanded_var_list, and might need to know that some variables can
overlap after they are expanded.

I will put a note in bug #9997 about this.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Reusing stack slots

[Zack Weinberg]

Jim Wilson <wilson@specifixinc.com> writes:

> This is not a 4 line fix.  We need to somehow record or replay scoping
> info for the variables in unexpanded_var_list, so we can overlap the
> space allocated for them when the scopes don't overlap.  We also may
> need changes in other places, for instance the aliasing code looks at
> unexpanded_var_list, and might need to know that some variables can
> overlap after they are expanded.

Or, possibly more easily, we could make stack-slot allocation aware of
the actual lifetimes of the variables on the list?  I would think this
information would be readily available as long as we are in SSA form.

zw

Re: Reusing stack slots

[Richard Henderson]

On Wed, Jul 07, 2004 at 07:28:11PM -0700, Zack Weinberg wrote:
> Or, possibly more easily, we could make stack-slot allocation aware of
> the actual lifetimes of the variables on the list?  I would think this
> information would be readily available as long as we are in SSA form.

We actually don't have this the way you think, particularly when
it comes to TREE_ADDRESSABLE variables.  It's something I've been
pondering the last couple of days.


r~

Re: Reusing stack slots

[Joern Rennecke]

> On Wed, Jul 07, 2004 at 07:28:11PM -0700, Zack Weinberg wrote:
> > Or, possibly more easily, we could make stack-slot allocation aware of
> > the actual lifetimes of the variables on the list?  I would think this
> > information would be readily available as long as we are in SSA form.
> 
> We actually don't have this the way you think, particularly when
> it comes to TREE_ADDRESSABLE variables.  It's something I've been
> pondering the last couple of days.

Maybe there should be a psudo-operations that indicates that an
addressable variable comes into or gets out of scope.
Sort of like a constructor / destructor pair.
You can the use alias information to see if the lifetime can be
reduced further - the start / end points may be moved across anything that
definitely doesn't alias the variable.

Re: Reusing stack slots

[Richard Henderson]

On Thu, Jul 08, 2004 at 07:18:13PM +0100, Joern Rennecke wrote:
> Maybe there should be a psudo-operations that indicates that an
> addressable variable comes into or gets out of scope.
> Sort of like a constructor / destructor pair.
> You can the use alias information to see if the lifetime can be
> reduced further - the start / end points may be moved across anything that
> definitely doesn't alias the variable.

Sure.  Something akin to that was discussed on irc yesterday.
Lots of niggly details to work out yet...


r~