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

Hi,

My recent refactoring of the (machine-dependent) use of <alloca.h>
does not attempt to change CWriter's behavior of emitting a #include
for <alloca.h>. FreeBSD does not have <alloca.h>, so this would
cause
trouble.

We could change it to emit an #ifndef __FreeBSD__...#endif around
#include <alloca.h>.  I suggest this because, I'm guessing, whether or
not the CWriter outputs pretty code is not of utmost importance.

Any counter-suggestions?

-Brian

-- 
gaeke at uiuc.edu

> We could change it to emit an #ifndef __FreeBSD__...#endif around
> #include <alloca.h>.  I suggest this because, I'm guessing,
whether or
> not the CWriter outputs pretty code is not of utmost importance.
Sounds reasonable.  It's not pretty, but the code output by the CWriter
already does an #ifdef sun (for alloca), so I don't think adding freebsd
would add any new level of uglyness.  :)

-Chris

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

Brian R. Gaeke wrote:
> Hi,
> 
> My recent refactoring of the (machine-dependent) use of <alloca.h>
> does not attempt to change CWriter's behavior of emitting a #include
> for <alloca.h>. FreeBSD does not have <alloca.h>, so this would
cause
> trouble.
> 
> We could change it to emit an #ifndef __FreeBSD__...#endif around
> #include <alloca.h>.  I suggest this because, I'm guessing,
whether or
> not the CWriter outputs pretty code is not of utmost importance.
> 
> Any counter-suggestions?
	Well, this should be fixed in the recent autoconf stuff that I've got 
working locally in my working directory.  I'd suggest using the 
HAVE_ALLOCA_H macro and plugging its definition into Makefile.Linux and 
Makefile.Sun until I check autoconf in.

	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).  Using normal 
allocation routines (malloc, new) would be more portable anyway.  I 
considered doing that just last week, but decided to leave it for now. 
If you're familiar with that code, I'd recommend changing it.

	Every man page for alloca I've seen (Linux, Solaris, NetBSD) 
essentially reads "alloca() is cool, but don't use it!!"	:)

-- John T.
> 
> -Brian
> 


-- 
*********************************************************************
* John T. Criswell                         Email: criswell at uiuc.edu *
*********************************************************************

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