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