llvm dev - May 2008 - [LLVMdev] malloc, magic, and embedded compilation

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

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

On Wed, 2008-05-14 at 16:15 +0200, Duncan Sands wrote:
> 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).
Umm. That sounds like a test case that really wants to get written.

Does the LLVM C front-end support the "init" attribute for C functions
(which has similar effect)?

shap

On May 14, 2008, at 7:15 AM, Duncan Sands wrote:
>> 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
The flag to disable assumptions about library functions selectively is
-fno-builtin, if that's actually what you want.  -ffreestanding is not  
quite the same;
it also disables special semantics for "main" and changes the  
predefinition of
__STDC_HOSTED__.
>> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Wed, May 14, 2008 at 8:27 AM, Jonathan S. Shapiro <shap at eros-os.com>
wrote:
> 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?
After compiling a few kernels with llvm (with LTO), I haven't seen one
yet that names any of it's allocators 'malloc', so in that case
it's
kind of a moot point.

As for the matter of entry points, this isn't a problem either lots of
things in a kernel (if properly marked 'used') don't get
internalized,
so you don't wind up with a bytecode that has a single entry point
named 'main'.  Oh, and main isn't a popular name for kernel entry
anyway.

Andrew