[LLVMdev] malloc, magic, and embedded compilation

[Dale Johannesen]

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