[LLVMdev] llvm-link as an extension

[hdwivedi at codeaurora.org]

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
>