[llvm-branch-commits] [RFC][Clang] Allow plugins to hook into back-end (PR #165257)
Alexis Engelke via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Mon Oct 27 08:29:10 PDT 2025
aengelke wrote:
> Would it make more sense to make the CodeGenAction and emitBackendOutput more flexible?
Maybe? emitBackendOutput (EmitAssemblyHelper) could call back into some new virtual method in BackendConsumer. This would leave the problem of inserting a new different (subclass of) BackendConsumer. But as a PluginASTAction cannot be a CodeGenAction, I would assume that at the very least the plugin action has to wrap all the virtual methods that CodeGenAction uses? This doesn't seem to be particularly viable, especially as some of the methods are protected. Duplicating CodeGenAction methods is also not a good option.
> It would be great to enhance the existing clang plugin system rather than adding a new plugin extension point.
I generally agree, but... I spent a few days trying to come up with a PluginASTAction that achieves something similar... and gave up (=> this patch). (I've not much experience with Clang plugins, but the code is rather complicated and sparsely documented, which doesn't help, either.)
> Do you mean that you will need to wrap clang's `BackendConsumer` into a `MultiplexConsumer` and overwrite its `HandleTranslationUnit` swapping `BackendConsumer::HandleTranslationUnit`'s `emitBackendOutput`?
Ideally, I don't want to swap emitBackendOutput, because I don't want to duplicate that logic...
https://github.com/llvm/llvm-project/pull/165257
More information about the llvm-branch-commits
mailing list