[LLVMdev] Linking libc statically to program and optimizations.

[Mikael Lepistö]

Hi,

I'll just reply to here if someone else encounters the same
problem.

With llvm-gcc -ffreestanding switch prevents raising the
memset, memcpy etc. function calls to llvm intrinsics.

-mikuli

Mikael Lepistö wrote:
> Hi,
>
> We have been working on porting llvm-gcc crosscompiler (basically I had 
> to create new dummy target configuration with some minimal information 
> about the our processor, endianess, type sizes, etc.) which compiles 
> llvm bytecode (doesn't compile native binaries nor assembler) for our 
> processor architecture and new llvm target for our custom processor. We 
> already managed to compile also newlib to llvm bytecode (archive of 
> bytecode objects packed with llvm-ar) with our crosscompiler.
>
> Right now we use tools like following. We first compile bytecode files 
> with cross-llvm-gcc and also link them together with cross-llvm-gcc 
> command for automatically including precompiled crt0, crtend and libc.a 
> files to fully linked bytecode program. After linking we run various 
> "opt" passes and finally we compile target assembler with llc.
>
> Now we ran into two problems:
>
> 1. When we link libc statically to our program in early phase of the 
> compilation linker automatically selects only those compile units, which 
> contain needed symbols from libc.a archive. So when cross-llvm-gcc 
> encounter malloc calls, they are automatically converted to malloc 
> instructions. So now when libc is linked statically, linker doesn't see 
> any malloc function references, and doesn't include malloc compilation 
> module from libc.a.
>
> Now it's fixed by lowering malloc instructions of program  directly 
> after each "cross-llvm-gcc -c" command. Other approach to this problem 
> was putting libc.a together with "llvm-ld -r" command instead of 
> llvm-ar... This way whole libc is always included to optimization stage 
> and  calling lowerallocs pass before dead code elimination passes. 
> Disadvantages is this approach was couple of seconds delay when 
> optimizing program and a bit larger binary (reasons for larger binary I 
> haven't investigated yet).
>
> 2. Memset, memcpy are replaced, with llvm intrinsics and because of that 
> implementations of those libc functions are optimized away before llc phase.
>
> I would like to have some comments especially how the lowering allocs in 
> early stage (1. problem) in the tce-llvm-gcc effects on optimization of 
> code and if there is way to lower also memcpy and memset intrinsics in 
> optimization phase  for preventing elimination of implementation of 
> these functions. Also all the other comments are more than welcome.
>
> -mikuli
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>