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 >