llvm dev - Dec 2014 - [LLVMdev] 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 :)

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

Regards,

Harsh

Qualcomm Innovation Center, Inc.

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

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

Hi Rafael,

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

Regards,

Harsh
> 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
>