[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