llvm-link as an extension

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 :slight_smile:

Sorry if this has been answered in the past, I just wondered what
downsides might be to this possible approach?



Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

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.


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.


Hi Rafael,

Thanks for your reply! Let me look at these interfaces.