[LLVMdev] CWriter outputs non-portable use of alloca.h

[Chris Lattner]

On Mon, 16 Jun 2003, Brian R. Gaeke wrote:
> There are two different issues here.

Yup.

> CWriter *outputs* alloca() calls so that it can be sure to output C code
> that correctly corresponds to the LLVM bytecode, which may have alloca
> instructions in it. I think we have little choice but to continue using
> alloca() here. I'm going to hack in an ifndef for FreeBSD around
> the declaration output by CWriter to fix this.

Sounds great, thanks!

> LLVM *calls* alloca() in various places because people prefer to use it,
> as stated above, for performance, and perhaps more significantly, to
> ease managing memory that will only be used during the lifetime of
> a particular function call. I might not personally choose to introduce
> more calls to alloca() in the compiler itself, but it doesn't seem to
> me to be an important enough issue that I would be driven to get rid of
> all the existing calls to alloca().

FWIW, I removed the two places that called alloca without really needing
to (I switched it to use new[]/delete[]).  The one place remaining we
actually need the alloca call _specifically_ as a work around for a
problem with the GCC generated code (gross I know).

Any good optimizing compiler (like LLVM? :)  should be able to turn a
malloc/free pair into an alloca call if it can prove that the value does
not escape and that the free post-dominates the malloc.  We don't do this
currently, but it is really trivial to implement, especially with the
DSGraph stuff (I think that one of the CS426 projects did this
transformation, among others).  For this reason, I don't think we should
introduce any extra alloca calls into the compiler, for portability
reasons.

That said, the header is useful and should stay.  The X86 JIT will
continue to use it until we find a more elegant solution.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/