================
@@ -233,6 +234,20 @@ bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
Clang->LoadRequestedPlugins();
+ // Load and store pass plugins for the back-end. Store the loaded pass
plugins
+ // here and store references to these in CodeGenOpts to avoid pulling in the
+ // entire PassPlugin dependency chain in CodeGenOpts.
+ std::vector<std::unique_ptr<llvm::PassPlugin>> PassPlugins;
+ for (const std::string &Path : Clang->getCodeGenOpts().PassPluginNames) {
----------------
weliveindetail wrote:
Not a blocker for this PR, but since the question comes up: There is a test
from https://github.com/llvm/llvm-project/pull/70171 that loads a LLVM plugin
through a dummy `PluginASTAction`. The additional `PassBuilderCallbacks` member
in `CodeGenOption` originates from this PR.
@wsmoses Is there a good reason for it not to use the LLVM plugin interface? If
yes, can we represent that in the test? If no, can we drop it?
https://github.com/llvm/llvm-project/pull/171868
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
