[LLVMdev] llvm-link as an extension

[Rafael Espíndola]

On 4 December 2014 at 00:11,  <hdwivedi at codeaurora.org> wrote:
> Hi all,
>
> I understood that llvm-link's capabilities are going to be merged in lld
> sometime in the future. However, would it be beneficial to make llvm-link
> itself a pluggable library which can be used by any linker?
>
> So say a linker, can have a flag like Wlinker=-enable-llvm-link, which
> uses a llvm-link library, like LD_LIBRARY_PATH=/path/to/llvm-link.so, that
> way llvm-link can use the symbol resolution table of this linker to link
> the IR code (so llvm-link doesn't have to have linker's logic).
>
> This will help extend the capability to have the full program IR, even
> when using other linkers other than lld and potentially simpler because
> llvm-link can use the linker's symbol resolution table for linker logic.
>
> One potential issue that I see with this approach, is when linking
> precompiled libraries which may not have any IR, in which case some
> annotation in the final IR could indicate that there is linkage with an
> object file.
>
> Also, I don't have a very clear idea if this would be an extremely heavy
> undertaking :)

Depending on what you want, it already exists.

lib/Linker contains 99% of the logic that llvm-link uses, but there is
a lot more to LTO than that. There are currently two implementations.
tools/lto (with lib/lto) implements the interface used by ld64. It is
simple, but somewhat restrictive. tools/gold implements the interface
used by gold.

I gave a talks on a previous dev meeting that covers some of the differences.

https://www.youtube.com/watch?v=9XUQ-1pI5_c

I intend to add support for ld64 once the current scalability issues
have been addressed. The logic should end up being fairly similar to
the one in tools/gold.

Cheers,
Rafael