[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

0–1

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

0–1

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

0–1

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

0–1

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

0–1

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?

clang/lib/Driver/ToolChains/CommonArgs.cpp

 //===--- CommonArgs.cpp - Args handling for multiple toolchains -*- C++ -*-===//
 //
 // 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
 //
 //===----------------------------------------------------------------------===//
 

 #endif
 
     SmallString<1024> Plugin;
     llvm::sys::path::native(Twine(ToolChain.getDriver().Dir) +
                                 "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold" +
                                 Suffix,
                             Plugin);
     CmdArgs.push_back(Args.MakeArgString(Plugin));
+
+    // Pass in our own path in case we need to reload
+    CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=self=") + Plugin));
   }
 
   // Try to pass driver level flags relevant to LTO code generation down to
   // the plugin.
 
   // Handle flags for selecting CPU variants.
   std::string CPU = getCPUName(Args, ToolChain.getTriple());
   if (!CPU.empty())

llvm/tools/gold/CMakeLists.txt

-set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/gold.exports)
-
 if( LLVM_ENABLE_PIC AND LLVM_BINUTILS_INCDIR )
   include_directories( ${LLVM_BINUTILS_INCDIR} )
 
   set(LLVM_LINK_COMPONENTS
      ${LLVM_TARGETS_TO_BUILD}
      Linker
      LTO
      BitWriter
      IPO
      )
 
   add_llvm_library(LLVMgold MODULE
     gold-plugin.cpp
     )
 
 endif()

llvm/tools/gold/gold-plugin.cpp

 //===-- gold-plugin.cpp - Plugin to gold for Link Time Optimization  ------===//
 //
 // 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
 //
 //===----------------------------------------------------------------------===//
 //

 #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;
+  // Path to ourselves, and whether we have been reloaded for pass plugin symbol
+  // resolution
+  static std::string self;
+  static bool self_reloaded = false;
 
   // 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.consume_front("opt-remarks-passes=")) {
       RemarksPasses = std::string(opt);
     } else if (opt == "opt-remarks-with-hotness") {
       RemarksWithHotness = true;
     } else if (opt.consume_front("opt-remarks-format=")) {
       RemarksFormat = std::string(opt);
     } else if (opt.consume_front("stats-file=")) {
       stats_file = std::string(opt);
+    } else if (opt.consume_front("self=")) {
+      // Store our own path, in case we need to be reloaded
+      self = std::string(opt);
+    } else if (opt.consume_front("load=")) {
+      std::string Error, Path(opt);
+
+      // This plugin is loaded by gold under RTLD_LOCAL, which means that our
+      // LLVM symbols are not available to subsequent pass plugins. Since this
+      // will break statically-built pass plugins, we reload with RTLD_GLOBAL.
+      if (!self_reloaded) {
+        if (self.size()) {
+          if (sys::DynamicLibrary::LoadLibraryPermanently(self.c_str(), &Error))
+            message(LDPL_ERROR, "Unable to reload LLVM gold plugin: %s",
+                    Error.c_str());
+          else
+            self_reloaded = true;
+        } else
+          message(LDPL_ERROR, "Unable to retrieve path to LLVM gold plugin!");
+      }
+
+      if (sys::DynamicLibrary::LoadLibraryPermanently(Path.c_str(), &Error))
+        message(LDPL_ERROR, "Unable to load plugin: %s", Error.c_str());
+    } else if (opt.consume_front("load-pass-plugin=")) {
+      pass_plugins.push_back(opt.data());
     } 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);
 }
 

llvm/tools/gold/gold.exports

-onload