Brian R. Gaeke
2003-Jun-16 16:57 UTC
[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
Chris Lattner
2003-Jun-16 17:11 UTC
[LLVMdev] CWriter outputs non-portable use of alloca.h
> 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/
John Criswell
2003-Jun-16 17:34 UTC
[LLVMdev] CWriter outputs non-portable use of alloca.h
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
Seemingly Similar Threads
- [LLVMdev] CWriter outputs non-portable use of alloca.h
- [LLVMdev] CWriter outputs non-portable use of alloca.h
- [LLVMdev] CWriter outputs non-portable use of alloca.h
- [LLVMdev] /usr/local/src/llvm/include/Config/alloca.h:42:17:#error "The function alloca()
- [LLVMdev] /usr/local/src/llvm/include/Config/alloca.h:42:17: #error "The function alloca()