[LLVMdev] LTO and Optimized libraries don't mix

[Rafael Espíndola]

On 9 June 2014 16:26, 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?
>

I don't think gold has an option for doing a full second pass.  What
is has is the ADD_INPUT_LIBRARY callback which should cause it to look
at the provided library again.

It is probably a good idea to try to find a convenient way to use it
from llvm. If the performance impact is not too horrible, it might
make sense to change gold-plugin.cpp to use that callback for every .a
that it sees that contains at least one native object file.

Cheers,
Rafael