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,
> > > >>>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