[opt] Ensure the IR-Linker is available to plugins.

[Meinersbur]

Summary

When using a statically linked opt executable (no BUILD_SHARED_LIBS or LLVM_LINK_LLVM_DYLIB), the linker only includes symbols used (directly or transitively) by the opt program itself. However, when loading another module using the "-load" mechanism from Passes/PassPlugin.cpp or Support/PluginLoader.cpp, it may require symbols that have not been included into the executable.

In this specific case, Polly uses the LLVM-IR linker, which is not included in the statically linked opt executable. As a result, some Polly regressions tests may fail with the error message

opt: symbol lookup error: LLVMPolly.so: undefined symbol: _ZN4llvm6LinkerC1ERNS_6ModuleE

(It does work using clang which uses the LLVM linker).

This patch ensures that the LLVMLinker is available in the opt executable by referencing it in one of opt's main object files. The exported symbol ensurePluginSymbols creates a linker object without being called anywhere.

This is a pragmatic fix for Polly and unfortunately does not solve the more general problem that not all symbols are available to plugins in statically linked tools. I am open for better solutions.

[mehdi_amini]

unfortunately does not solve the more general problem that not all symbols are available to plugins in statically linked tools. I am open for better solutions.

What about "force-load" the archive libraries on link? See what we do in MLIR here: https://github.com/tensorflow/mlir/blob/master/CMakeLists.txt#L22

[serge-sans-paille]

@Meinersbur what about linking with LLVM-IR linker in your shared module?

[Meinersbur]

In D65295#1601930, @mehdi_amini wrote:

What about "force-load" the archive libraries on link? See what we do in MLIR here: https://github.com/tensorflow/mlir/blob/master/CMakeLists.txt#L22

Thank you for the suggestion. During a first test with --whole-archive, I got multiple definitions errors. I will try a bit more.

As another possibility in cmake we could link the object libraries instead of the archive,

In D65295#1602219, @serge-sans-paille wrote:

@Meinersbur what about linking with LLVM-IR linker in your shared module?

This would cause global variables to be present multiple times within the same address space. If it is an cl::opt, it will immediately error-out.

[beanz]

The CMake build system option PLUGIN_TOOL on add_llvm_loadable_module is for this specific purpose, it instructs the link step for the plugin dylib to resolve symbols against the tool.

Polly likely needs to generate different libraries for being a clang plugin vs being an opt plugin, but that is expected and the correct solution to this problem.

[Meinersbur]

In D65295#1602763, @beanz wrote:

The CMake build system option PLUGIN_TOOL on add_llvm_loadable_module is for this specific purpose, it instructs the link step for the plugin dylib to resolve symbols against the tool.

Polly likely needs to generate different libraries for being a clang plugin vs being an opt plugin, but that is expected and the correct solution to this problem.

Thank you for the hint. I was under the impression that this option was added to allow plugins under Windows. I will try it out.

If this is the proper way, why do we even support add_llvm_library(${NAME} MODULE without PLUGIN_TOOL?

[beanz]

In D65295#1602891, @Meinersbur wrote:

If this is the proper way, why do we even support add_llvm_library(${NAME} MODULE without PLUGIN_TOOL?

The LLVMGold plugin's loader tool isn't part of the LLVM build tree.

[mehdi_amini]

In D65295#1602763, @beanz wrote:

The CMake build system option PLUGIN_TOOL on add_llvm_loadable_module is for this specific purpose, it instructs the link step for the plugin dylib to resolve symbols against the tool.

Polly likely needs to generate different libraries for being a clang plugin vs being an opt plugin, but that is expected and the correct solution to this problem.

I'm not sure I understood: does it mean that the plugin dylib would embed the symbols it needs unless it finds them inside the tool (opt)?

tools/opt/CMakeLists.txt

set(LLVM_LINK_COMPONENTS
   ObjCARCOpts
   Remarks
   ScalarOpts
   Support
   Target
   TransformUtils
   Vectorize
   Passes
+  Linker
   )
 
 # Support plugins.
 set(LLVM_NO_DEAD_STRIP 1)
 
 add_llvm_tool(opt
   AnalysisWrappers.cpp
   BreakpointPrinter.cpp
   Debugify.cpp
+  EnsurePluginSymbols.cpp
   GraphPrinters.cpp
   NewPMDriver.cpp
   PassPrinters.cpp
   PrintSCC.cpp
   opt.cpp
 
   DEPENDS
   intrinsics_gen
   )
 export_executable_symbols(opt)
 
 if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
   target_link_libraries(opt PRIVATE Polly)
 endif(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)

tools/opt/EnsurePluginSymbols.cpp

+//===- EnsurePluginSymbols.cpp - ------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// Plugins via the -load mechanism may require symbols that opt itself does not
+// use. This file ensures that those symbols are added to the executable by the
+// static library linker.
+//
+//===----------------------------------------------------------------------===//
+
+#include "llvm/IR/Module.h"
+#include "llvm/Linker/Linker.h"
+
+using namespace llvm;
+
+void ensurePluginSymbols() {
+  LLVMContext C;
+  Module M("", C);
+
+  // Linker is e.g. required by Polly's GPGPU generator to link libdevice with
+  // user code.
+  Linker L(M);
+}