This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Lowering of VLA's
Hello,
> > > > This change does not yet make VLA's fully independent on enclosing BIND_EXPR,
> > > > since there is the stack deallocation part that is still carried by
> > > > BIND_EXPR; changes to make this explicit should follow.
> > >
> > > Hmm. I suppose that means introducing some concept of stack management
> > > into tree-ssa?
> >
> > It should be enough to have magic statements STACK_SAVE and
> > STACK_RESTORE (used like
> >
> > stack_temp = STACK_SAVE;
> > ...
> > STACK_RESTORE stack_temp;)
> >
>
> I hope we dont have to go teaching all the existing optimizations about
> new tree codes...
there is nothing much special about them; at least the current patch
(explicit stack allocation) did not needed any special handling
(except of course in tree-dfa).
> do we really reclaim stack space coming out of a BIND_EXPR?
Yes, consider
for (i = 10; i < 100000; i++)
{
int a[i];
...
}
we really don't want to run out of stack here.
> Do we
> allocate space with alloca?
Not in this case.
> is there a dealloca()? I wasnt aware of it.
No, afaik.
> Or are these allocations done with malloc/free?
No. The stack space is allocated directly.
> If so, can't we simply
> expose the calls to malloc/free at the begin/end of the BIND_EXPR and
> not have to worry about any magic or new tree codes?
These new magic codes require about the same amount of handling as these
functions need. In fact I have considered making them just specially
handled function calls; but it seemed to be cleaner this way to me.
Zdenek