llvm dev - Jun 2003 - [LLVMdev] CWriter outputs non-portable use of alloca.h

On Mon, 2003-06-16 at 17:33, John Criswell wrote:
> 	What would be better yet is to modify the code so that it does not use 
> alloca() at all.  There seems to be little reason to use it aside from 
> convenience (but perhaps I have missed something).  
I think the idea is that alloca can give (probably significant)
performance gains when used properly.  In the cases where you need
dynamic memory for some task but it doesn't need to have a lifetime
longer than the current function context, etc., using alloca() would be
faster because there'd be no heap management involved.  Also, on some
platforms (in particular, SparcV9) the alloca is implemented as little
more than an %sp adjustment, so it's nice and quick.

In practice, you're probably right that malloc() is more portable, but I
dunno.

Just FYI...

-j

> On Mon, 2003-06-16 at 17:33, John Criswell wrote:
> > 	What would be better yet is to modify the code so that it does not
use
> > alloca() at all.  There seems to be little reason to use it aside from
> > convenience (but perhaps I have missed something).  
> 
> I think the idea is that alloca can give (probably significant)
> performance gains when used properly.
There are two different issues here.

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.

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

-- 
gaeke at uiuc.edu

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/