[LLVMdev] Linking libc statically to program and optimizations.
mikael.lepisto at tut.fi
Mon Jul 2 00:52:44 PDT 2007
I'll just reply to here if someone else encounters the same
With llvm-gcc -ffreestanding switch prevents raising the
memset, memcpy etc. function calls to llvm intrinsics.
Mikael Lepistö wrote:
> 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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev