[tree-ssa] Lowering of VLA's

Zdenek Dvorak rakdver@atrey.karlin.mff.cuni.cz
Mon Aug 25 19:53:00 GMT 2003


Hello,

> > > >>>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?
> > > 
> > > Yes.
> > > I can already see the pain new opcodes would cause me in SSAPRE load 
> > > optimization (it's not that hard to handle it in PTA)
> > 
> > no more than calls. Just handle them the same way.
> > 
> 
> The point is calls are already handled, we dont have to add anything
> anywhere.

except that you will have to look everywhere where calls are handled and
check whether it does not change anything.

> > > Please don't add opcodes for things builtin calls handle adequately.
> > > These really should be __builtin_stack_alloc (size_t) __attribute__ 
> > > (malloc) or whatever.
> > > Repeat after me: Calls do not make code motion harder to program.  
> > > Special side-effecting opcodes do.
> > 
> > Calls that do not behave exactly as calls would just make troubles on
> > other places.
> 
> Doesn't it behave exactly like a call which is inlined and bumps the
> stack pointer?

In current state, no.  Once allocation and deallocation is added, I
agree making them just function calls may be best (I will have to think
about it more; still I fear some interaction with rest of gcc).

Zdenek



More information about the Gcc-patches mailing list