[gold] Add support for loading pass plugins

[ddcc]

Summary

Add a -load and -load-pass-plugin for dynamically loading plugin passes into old/new PM during LTO when using gold. LLVM already exposes LTO pass extension points, e.g. EP_FullLinkTimeOptimizationEarly, but currently the gold plugin doesn't seem to support actually loading plugins.

[tmsriram]

Maybe add a parent child relationship with D77705. I have some familiarity with gold plugins and can take a look at this, could you please add more details to the summary?

[ddcc]

Sure. I've written some local optimizations in a loadable pass that uses one of the LTO extension points, EP_FullLinkTimeOptimizationEarly, but it seems that there's no way to actually load out-of-tree LTO passes into gold. This patch fixes that by modifying the gold plugin to support two additional arguments for loading external passes with the old/new pass manager, though I've only tested it with my local legacy pass.

However, I wasn't able to successfully load my pass until I rebuilt my local Clang/LLVM with LLVM_LINK_LLVM_DYLIB so that everything is dynamically linked to libLLVM.so. Otherwise, when both the loadable pass and the LLVM gold plugin are built statically, everything is initialized twice, which leads to an error at runtime about duplicate argument registration. Alternatively, when the loadable pass is built dynamically without an explicit dependency on libLLVM.so, it wasn't able to reuse the LLVM symbols provided by a statically-linked LLVM gold plugin that is already loaded, because gold doesn't call dlopen with RTLD_GLOBAL when it is loading gold plugins, and the LLVM gold plugin has a LLVM_EXPORTED_SYMBOL_FILE that restricts exported symbols. Furthermore, loadable passes can depend on other components of LLVM, e.g. my pass uses the Demangler, which isn't linked into the LLVM gold plugin anyway. I'm not too familiar with pass registration and this part of the LLVM codebase, so perhaps there's a better way to get things working.

Edit 1: lld might have a similar problem, but I didn't look into it since my local toolchain is only using gold.

Edit 2: The arguments for loading plugins seem to be inconsistent between opt (-load/-load-pass-plugin) and clang (-Xclang -load/-fplugin/-fplugin-pass), so I just reused the former.

[tmsriram]

In D77704#1971183, @ddcc wrote:

Sure. I've written some local optimizations in a loadable pass that uses one of the LTO extension points, EP_FullLinkTimeOptimizationEarly, but it seems that there's no way to actually load out-of-tree LTO passes into gold. This patch fixes that by modifying the gold plugin to support two additional arguments for loading external passes with the old/new pass manager, though I've only tested it with my local legacy pass.

However, I wasn't able to successfully load my pass until I rebuilt my local Clang/LLVM with LLVM_LINK_LLVM_DYLIB so that everything is dynamically linked to libLLVM.so. Otherwise, when both the loadable pass and the LLVM gold plugin are built statically, everything is initialized twice, which leads to an error at runtime about duplicate argument registration. Alternatively, when the loadable pass is built dynamically without an explicit dependency on libLLVM.so, it wasn't able to reuse the LLVM symbols provided by a statically-linked LLVM gold plugin that is already loaded, because gold doesn't call dlopen with RTLD_GLOBAL when it is loading gold plugins, and the LLVM gold plugin has a LLVM_EXPORTED_SYMBOL_FILE that restricts exported symbols. Furthermore, loadable passes can depend on other components of LLVM, e.g. my pass uses the Demangler, which isn't linked into the LLVM gold plugin anyway. I'm not too familiar with pass registration and this part of the LLVM codebase, so perhaps there's a better way to get things working.

Thanks for providing more details. I do understand your issue with LLVM gold plugin and how libLLVM is linked but I dont have a good solution. Maybe you can mail llvm-dev to see if this can be worked out.

Edit 1: lld might have a similar problem, but I didn't look into it since my local toolchain is only using gold.

Edit 2: The arguments for loading plugins seem to be inconsistent between opt (-load/-load-pass-plugin) and clang (-Xclang -load/-fplugin/-fplugin-pass), so I just reused the former.

Alright, is it feasible to add small tests or provide instructions on how you would load an example pass?

Sorry if my comments aren't too helpful :(.

[ddcc]

Alright, is it feasible to add small tests or provide instructions on how you would load an example pass?

Sure, I'm just not sure how to fit this into the testing infrastructure. I don't think this could work with any of the FileCheck-based test since I'd need to build a separate pass and load the binary? I can also modify the GoldPlugin.rst to mention these arguments for loading passes? Ideally though, it would be pretty transparent; once the Clang driver changes land, there'd be no difference compared to loading a regular LLVM pass.

Do you have suggestions for any other reviewers?

[efriedma]

It looks like this overlaps with https://reviews.llvm.org/D76866 ; maybe wait for that to merge, then we can handle the gold-specific changes as a followup.

(Probably you need export_executable_symbols_for_plugins to fix the missing symbol issues.)

[ddcc]

In D77704#1978430, @efriedma wrote:

It looks like this overlaps with https://reviews.llvm.org/D76866 ; maybe wait for that to merge, then we can handle the gold-specific changes as a followup.

(Probably you need export_executable_symbols_for_plugins to fix the missing symbol issues.)

Oh, didn't see that you're working on something similar. Sure, thanks for the suggestions.

[ddcc]

Rebase

[ddcc]

Here's the updated patch, though it still only works when LLVM is built with LLVM_LINK_LLVM_DYLIB=ON. Otherwise, with or without the LLVM_EXPORTED_SYMBOL_FILE definition, I get the following error with a static build:

Unable to load plugin: <pass>.so: undefined symbol: _ZNK4llvm4Pass11getPassNameEv

[efriedma]

llvm/tools/gold/CMakeLists.txt

1 ↗

(On Diff #257598)

Oh, duh, I just realized the problem with the symbol exports. The LLVM_EXPORTED_SYMBOL_FILE line suppresses exporting all the symbols pass plugins would normally use.

(And I should have realized export_executable_symbols_for_plugins shouldn't be necessary for a shared library: shared libraries export all symbols by default.)

[ddcc]

llvm/tools/gold/CMakeLists.txt

1 ↗

(On Diff #257598)

Hmm, I tried both with and without LLVM_EXPORTED_SYMBOL_FILE, but it didn't seem to make a difference.

I think the fundamental problem here is that when gold calls dlopen(LLVMgold.so, RTLD_LAZY), it doesn't load provide the RTLD_GLOBAL argument, so any symbols in LLVMgold.so aren't available to subsequent dynamically-loaded plugins.

[efriedma]

llvm/tools/gold/CMakeLists.txt

1 ↗

(On Diff #257598)

Oh, hmm, that makes sense. That's harder to solve.

We could make LLVMgold.so dlopen() itself, I guess? That seems terribly hacky, though.

[ddcc]

llvm/tools/gold/CMakeLists.txt

1 ↗

(On Diff #257598)

I haven't tried it, but I'm not sure if that would work. Wouldn't there be two copies of LLVM loaded into gold, with each initialized separately? It seems like a proper fix would be in gold itself, but otherwise, I'd consider having this working for LLVM_LINK_LLVM_DYLIB still an improvement.

[efriedma]

llvm/tools/gold/CMakeLists.txt

1 ↗

(On Diff #257598)

Shared libraries are reference-counted, so it should be possible to do this without loading a second copy.

[ddcc]

Support statically-built passes

[ddcc]

Thanks, seems to be working now for statically-built passes on a default LLVM build without LLVM_LINK_LLVM_DYLIB.

[ddcc]

In order to reload the gold plugin, I'm modifying the Clang driver to pass in our own path as a separate argument, which is the most generic approach. Another method would be to use e.g. dladdr() to grab our own path from one of our exported functions, but that method appears to be a glibc extension which isn't cross-platform.

[ddcc]

ping, any feedback?

llvm/include/llvm/LTO/Config.h

struct Config {
   DiagnosticHandlerFunction DiagHandler;
 
   /// If this field is set, LTO will write input file paths and symbol
   /// resolutions here in llvm-lto2 command line flag format. This can be
   /// used for testing and for running the LTO pipeline outside of the linker
   /// with llvm-lto2.
   std::unique_ptr<raw_ostream> ResolutionFile;
 
+  /// Plugins to be loaded by PassManager.
+  std::vector<std::string> PassPlugins;
+
   /// Tunable parameters for passes in the default pipelines.
   PipelineTuningOptions PTO;
 
   /// The following callbacks deal with tasks, which normally represent the
   /// entire optimization and code generation pipeline for what will become a
   /// single native object file. Each task has a unique identifier between 0 and
   /// getMaxTasks()-1, which is supplied to the callback via the Task parameter.
   /// A task represents the entire pipeline for ThinLTO and regular

llvm/lib/LTO/LTOBackend.cpp

 #include "llvm/IR/LLVMRemarkStreamer.h"
 #include "llvm/IR/LegacyPassManager.h"
 #include "llvm/IR/PassManager.h"
 #include "llvm/IR/Verifier.h"
 #include "llvm/LTO/LTO.h"
 #include "llvm/MC/SubtargetFeature.h"
 #include "llvm/Object/ModuleSymbolTable.h"
 #include "llvm/Passes/PassBuilder.h"
+#include "llvm/Passes/PassPlugin.h"
 #include "llvm/Passes/StandardInstrumentations.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Program.h"
 #include "llvm/Support/SmallVectorMemoryBuffer.h"
 #include "llvm/Support/TargetRegistry.h"
static void runNewPMPasses(const Config &Conf, Module &Mod, TargetMachine *TM,
   }
 
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI;
   SI.registerCallbacks(PIC);
   PassBuilder PB(TM, Conf.PTO, PGOOpt, &PIC);
   AAManager AA;
 
+  // Load pass plugins if available
+  for (auto &P : Conf.PassPlugins) {
+    auto PassPlugin = PassPlugin::Load(P);
+    if (PassPlugin) {
+      PassPlugin->registerPassBuilderCallbacks(PB);
+    } else {
+      report_fatal_error("Unable to load pass plugin '" + P + "': " +
+                         toString(PassPlugin.takeError()));
+    }
+  }
+
   // Parse a custom AA pipeline if asked to.
   if (auto Err = PB.parseAAPipeline(AA, "default"))
     report_fatal_error("Error parsing default AA pipeline");
 
   LoopAnalysisManager LAM(Conf.DebugPassManager);
   FunctionAnalysisManager FAM(Conf.DebugPassManager);
   CGSCCAnalysisManager CGAM(Conf.DebugPassManager);
   ModuleAnalysisManager MAM(Conf.DebugPassManager);

llvm/tools/gold/gold-plugin.cpp

 #include "llvm/Config/config.h" // plugin-api.h requires HAVE_STDINT_H
 #include "llvm/IR/Constants.h"
 #include "llvm/IR/DiagnosticPrinter.h"
 #include "llvm/LTO/Caching.h"
 #include "llvm/LTO/LTO.h"
 #include "llvm/Object/Error.h"
 #include "llvm/Support/CachePruning.h"
 #include "llvm/Support/CommandLine.h"
+#include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/Threading.h"
 #include "llvm/Support/raw_ostream.h"
 #include <list>
#endif
   // Debug new pass manager
   static bool debug_pass_manager = false;
   // Directory to store the .dwo files.
   static std::string dwo_dir;
   /// Statistics output filename.
   static std::string stats_file;
   // Asserts that LTO link has whole program visibility
   static bool whole_program_visibility = false;
+  // List of new PM pass plugins
+  static std::vector<std::string> pass_plugins;
 
   // Optimization remarks filename, accepted passes and hotness options
   static std::string RemarksFilename;
   static std::string RemarksPasses;
   static bool RemarksWithHotness = false;
   static std::string RemarksFormat;
 
   // Context sensitive PGO options.
static void process_plugin_option(const char *opt_)
     } else if (opt.startswith("opt-remarks-passes=")) {
       RemarksPasses = std::string(opt.substr(strlen("opt-remarks-passes=")));
     } else if (opt == "opt-remarks-with-hotness") {
       RemarksWithHotness = true;
     } else if (opt.startswith("opt-remarks-format=")) {
       RemarksFormat = std::string(opt.substr(strlen("opt-remarks-format=")));
     } else if (opt.startswith("stats-file=")) {
       stats_file = std::string(opt.substr(strlen("stats-file=")));
+    } else if (opt.startswith("load=")) {
+      std::string Error, Path(opt.substr(strlen("load=")));
+
+      if (sys::DynamicLibrary::LoadLibraryPermanently(Path.c_str(), &Error))
+        message(LDPL_ERROR, "Unable to load plugin: %s", Error.c_str());
+    } else if (opt.startswith("load-pass-plugin=")) {
+      pass_plugins.push_back(
+          std::string(opt.substr(strlen("load-pass-plugin="))));
     } else {
       // Save this option to pass to the code generator.
       // ParseCommandLineOptions() expects argv[0] to be program name. Lazily
       // add that.
       if (extra.empty())
         extra.push_back("LLVMgold");
 
       extra.push_back(opt_);
static std::unique_ptr<LTO> createLTO(IndexWriteCallback OnIndexWrite,
   Conf.RemarksPasses = options::RemarksPasses;
   Conf.RemarksWithHotness = options::RemarksWithHotness;
   Conf.RemarksFormat = options::RemarksFormat;
 
   // Use new pass manager if set in driver
   Conf.UseNewPM = options::new_pass_manager;
   // Debug new pass manager if requested
   Conf.DebugPassManager = options::debug_pass_manager;
+  // Pass plugins to load
+  Conf.PassPlugins = std::move(options::pass_plugins);
 
   Conf.HasWholeProgramVisibility = options::whole_program_visibility;
 
   Conf.StatsFile = options::stats_file;
   return std::make_unique<LTO>(std::move(Conf), Backend,
                                 options::ParallelCodeGenParallelismLevel);
 }