[LLVMdev] malloc, magic, and embedded compilation

Jonathan S. Shapiro shap at eros-os.com
Wed May 14 06:27:00 PDT 2008


The discussion of malloc optimization from two (three?) weeks ago
prompts me to be concerned about implications for kernel compilation.
Basically, I have two questions:

1. The particular optimization that was done there was based on the
compiler substituting an alternate implementation of malloc(). This may
not be appropriate in kernel or deeply embedded systems. Is there a way
for someone who is building that sort of system to enable/disable the
builtin library magic selectively?

I assume that LLVM can support compiling for a "freestanding" C library,
and that this should disable everything of this sort, but it would be
useful to be able to then selectively re-enable things like memcpy.

2. The particular optimization in that case was also based on knowledge
that main() is not re-entrant, main() called f() once, f() called
malloc() once, and therefore that call to malloc() could be partially
evaluated at compile time. In kernels and such, main() is not the only
entry point and this particular optimization can't be done safely
without a whole-program view of all entry points.

What options do we need to provide to deal with this sort of thing?


shap




More information about the llvm-dev mailing list