[clang] [lld] [llvm] [LTO] Invoke PreCodeGenCallback of pass plugins in the LTO backend (PR #231516)

Antonio Frighetto via cfe-commits cfe-commits at lists.llvm.org
Mon Oct 19 00:20:26 PDT 2026


Stefan =?utf-8?q?Gränitz?= <stefan.graenitz at gmail.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/231516 at github.com>


================
@@ -199,23 +199,34 @@ Error Config::addSaveTemps(std::string OutputFileName, bool UseInputModulePath,
 #include "llvm/Support/Extension.def"
 #undef HANDLE_EXTENSION
 
+// Obtain dynamic pass-plugins in registration order: the ones requested by file
+// name followed by those pre-loaded in the host application
+static SmallVector<PassPlugin *, 2>
+getPassPlugins(const Config &Conf, SmallVectorImpl<PassPlugin> &Storage) {
+  for (const std::string &PluginFN : Conf.PassPluginFilenames) {
+    Expected<PassPlugin> Plugin = PassPlugin::load(PluginFN);
----------------
antoniofrighetto wrote:

> We do have multiple loads today already: in the thinBackend() case we load them once on each thread.

This would probably argue for fixing this, rather than extending on this pattern :)

Would it make sense instead to load pass plugins before backend()/thinBackend() run, once eagerly in LTO::run()? We could maintain a vector of pointers of PassPlugin objects (which would be alive for the entire duration of run()), such that opt() and codegen() would simply reuse the already-loaded plugins. This would avoid the repetitive dlopen()/dlsym() calls on every backend invocation (which would likely matter more esp. in ThinLTO).

https://github.com/llvm/llvm-project/pull/231516


More information about the cfe-commits mailing list