Stefan =?utf-8?q?Gränitz?= <[email protected]>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>
================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
