Re: [tree-ssa] Lowering of VLA's

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2003-08-25 at 13:42, Zdenek Dvorak wrote:

> > 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).
> 

I was thinking more of missing things rather than correctness. PLus we
probably arent doing a while lot of interesting things yet I suppose.

> 
> > Or are these allocations done with malloc/free?
> 
> No.  The stack space is allocated directly.

By the processing of the BIND_EXPR, which we are going to make go away.
So it conceptually bumps the stack size and decrements it at the
appropriate places?

> 
> > 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.
> 
But arent there subtle side effects optimizations might need to consider
that a function call would expose, or that they need to be taught about
the new opcode?

ie something like:

int x,y;
  {
    x = call1();
    y = call2();
    {
      int a[y];
       {
         int b[x];
         ...
       }
    }

if we switch this to magic opcodes, we'd see something like:

int x,y
x = call1()
y = call2()
a = STACK_ALLOC (y)
b = STACK_ALLOC(x)
STACK_DEALLOC (b)
STACK_DEALLOC (a)

there is no ordering implied any more with the BIND_EXPR's gone, so code
motion could then make this:

x = call1()
b = STACK_ALLOC (x)
y = call2()
a = STACK_ALLOC(y)
STACK_DEALLOC (b)
STACK_DEALLOC (a)

which is going to deallocate them in the wrong order. 

If they are represented as calls, then the allocation of b would not get
moved above the allocation of a because we already understand enough
about them to know we cant do this.

Or you have to teach the SSA renamer to provde a special virtual operand
variable to keep the ordering properly. something like:

int x,y
x = call1()
y = call2()
# stack_alloc_1 = VDEF <stack_alloc_0>
a = STACK_ALLOC (y)
# stack_alloc_2 = VDEF <stack_alloc_1>
b = stack_ALLOC(x)
# VUSE <stack_alloc_2>
STACK_DEALLOC (b)
# VUSE <stack_alloc_1>
STACK_DEALLOC (a)


Same thing holds true for the DEALLOCS. There doesnt appear to be any
reson why the DEALLOC use can't be moved right up to the def point. Uses
can be moved by each other unless there are side effects...  

Andrew