Following on from my last question, based on such information as I’ve been able to find on Google, I get the impression llvm-link is effectively deprecated / not actively maintained, because the focus of whole-program optimization is now on the gold plugin. Is that the case, or am I missing something?
Running searches over the source tree, it seems the Linker class that actually implements the functionality of llvm-link is not used by any other modules except LTOCodeGenerator. I couldn’t find anything referencing LTOCodeGenerator. Does the gold plugin or anything else use LTOCodeGenerator?
LTOCodeGenerator is used by the llvm-lto tool, which is a standalone
tool for doing LTO links.
Ah! Okay. A quick test of llvm-lto gets an error:
llvm-lto: error adding file ‘main.bc’: Linking COMDATs named ‘??_7_Iostream_error_category@std@@6B@’: invalid selection kinds!
Would it be the case that llvm-lto is also deprecated in favor of the gold plugin?
I don't recall hitting that but I am using a modified version of
llvm-lto and the linking code to work on an LTO-related prototype (I
find llvm-lto is easier than using the linker plugin for testing). My
source code bits are also a little stale though.
But llvm-lto is generally just a wrapper around the code that does the
linking, which is shared with the gold plugin, and is where that
assert comes from. So I am not sure why it would give an error like
that assuming these are the same bitcode files you can successfully
feed into an LTO link using gold.
Ah, so the gold plugin does use the same Linker class as the other tools, so that code should be considered current and actively maintained? Thanks.
I tried my test case just now with llvm-link on Linux and it worked correctly, so I’m guessing there’s a bug in the way the Linker class works on Windows.
llvm-link and llvm-lto are developer tools. They exist only as a way
of making portable tests easy to write.