[LLVMdev] malloc, magic, and embedded compilation

[Duncan Sands]

> 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?

-ffreestanding

> 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?

I don't think the logic is based on "main", but on whether functions
are marked "internal" or not.  That said, GlobalOpt.cpp seems to reason
based on the name "main" (most likely bogus, because of constructors/
destructors running before main).

Ciao,

Duncan.