[LLVMdev] LTO and Optimized libraries don't mix

[Nick Kledzik]

Daniel,

This has been a recurring issue with LTO on darwin too.   To fix most issues, I added an enhancement to the linker whenever it was dealing with LTO.  After the LTO codegen was done, if any new undefined symbols appeared, the link made another pass looking for definitions in dylibs (DSO).  This solved almost all issues because memcpy and friends are implemented in libSystem.dylib on darwin.  The remaining cases were for static programs (embedded, EFI, etc) which don’t use dylibs.  For them, the current work around is to add -U as needed on the linker command line (e.g. -U _memcpy) which forces the linker to retain a copy of that runtime utility function.

-Nick


On Jun 9, 2014, at 1:26 PM, Daniel Stewart <stewartd at codeaurora.org> wrote:
> When using the ARM cross compiler we’ve run into an issue with LTO and optimized libraries.
>  
> Consider you have an optimized library opt.a, which contains a version of memcpy.
>  
> Compiling with LTO (something like),
> clang myTest.c opt.a –flto –o myTest
>  
> causes myTest.c to get compiled to bitcode.
>  
> Then the bitcode gets passed to the linker. The linker looks through the bitcode (via the gold plugin) searching for symbols it needs to resolve. But  any memcpy() calls in myTest.c got converted to llvm.memcpy() calls in the bitcode. Any symbols that start with ‘llvm.’ get ignored in LTOModule.cpp. So the linker doesn’t know that it needs memcpy. Now once the linker processes opt.a it doesn’t know that it needs memcpy, so the linker doesn’t keep the definition of memcpy from opt.a.
>  
> After the (full) compilation of myTest is complete, the linker winds up trying to pull memcpy from libc. But once it hits opt.a to process again, it sees a multiple definition issue.
>  
> It appears that optimized libraries and LTO don’t currently mix well. Does anyone have any insight about how this should be accomplished?
>  
> Daniel
>  
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>  
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140609/940f53f4/attachment.html>