-
Notifications
You must be signed in to change notification settings - Fork 15.4k
[RFC][LLVM][Clang] Add LLVM plugin hook for back-ends #170846
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: users/aengelke/spr/main.rfcllvmclang-add-llvm-plugin-hook-for-back-ends
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -14,14 +14,17 @@ | |
| #define LLVM_PASSES_PASSPLUGIN_H | ||
|
|
||
| #include "llvm/ADT/StringRef.h" | ||
| #include "llvm/Support/CodeGen.h" | ||
| #include "llvm/Support/Compiler.h" | ||
| #include "llvm/Support/DynamicLibrary.h" | ||
| #include "llvm/Support/Error.h" | ||
| #include <cstdint> | ||
| #include <string> | ||
|
|
||
| namespace llvm { | ||
| class Module; | ||
| class PassBuilder; | ||
| class TargetMachine; | ||
|
|
||
| /// \macro LLVM_PLUGIN_API_VERSION | ||
| /// Identifies the API version understood by this plugin. | ||
|
|
@@ -30,14 +33,15 @@ class PassBuilder; | |
| /// against that of the plugin. A mismatch is an error. The supported version | ||
| /// will be incremented for ABI-breaking changes to the \c PassPluginLibraryInfo | ||
| /// struct, i.e. when callbacks are added, removed, or reordered. | ||
| #define LLVM_PLUGIN_API_VERSION 1 | ||
| #define LLVM_PLUGIN_API_VERSION 2 | ||
|
|
||
| extern "C" { | ||
| /// Information about the plugin required to load its passes | ||
| /// | ||
| /// This struct defines the core interface for pass plugins and is supposed to | ||
| /// be filled out by plugin implementors. LLVM-side users of a plugin are | ||
| /// expected to use the \c PassPlugin class below to interface with it. | ||
| /// be filled out by plugin implementors. Unused function pointers can be set to | ||
| /// nullptr. LLVM-side users of a plugin are expected to use the \c PassPlugin | ||
| /// class below to interface with it. | ||
| struct PassPluginLibraryInfo { | ||
| /// The API version understood by this plugin, usually \c | ||
| /// LLVM_PLUGIN_API_VERSION | ||
|
|
@@ -49,7 +53,14 @@ struct PassPluginLibraryInfo { | |
|
|
||
| /// The callback for registering plugin passes with a \c PassBuilder | ||
| /// instance | ||
| void (*RegisterPassBuilderCallbacks)(PassBuilder &); | ||
| void (*RegisterPassBuilderCallbacks)(PassBuilder &) = nullptr; | ||
|
|
||
| /// Callback called before running the back-end passes on the module. The | ||
| /// callback can generate code itself by writing the expected output to OS and | ||
| /// returning true to prevent the default pipeline and further plugin | ||
| /// callbacks from running. | ||
| bool (*PreCodeGenCallback)(Module &, TargetMachine &, CodeGenFileType, | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the idea to have pre/post opt/codegen callbacks. If we ever get the new pass manager in the Codegen pipeline, that would help plugins to handle the pipeline change. Could we generalize this into something like
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would consider this to be out-of-scope for now. Back-end pipelines are, currently, target-specific and any support for plugins modifying these pipelines is likely to need a lot of further discussion (esp. as many back-end passes not really self-contained). There was some discussion on CodeGenPassBuilder to add callbacks for targets earlier this year, but it seems work on that has stalled. Additionally, the proposed plugin API already permits building and running a custom pass manager, so right now there would be no benefit of speculatively building a more generic API. If there's a desire to add external hooks for CodeGenPassBuilder, I think this should be a separate function similar to the RegisterPassBuilderCallbacks that exists so far. |
||
| raw_pwrite_stream &OS) = nullptr; | ||
| }; | ||
| } | ||
|
|
||
|
|
@@ -80,7 +91,17 @@ class PassPlugin { | |
|
|
||
| /// Invoke the PassBuilder callback registration | ||
| void registerPassBuilderCallbacks(PassBuilder &PB) const { | ||
| Info.RegisterPassBuilderCallbacks(PB); | ||
| if (Info.RegisterPassBuilderCallbacks) | ||
| Info.RegisterPassBuilderCallbacks(PB); | ||
| } | ||
|
|
||
| /// Invoke the pre-codegen callback. | ||
| bool invokePreCodeGenCallback(Module &M, TargetMachine &TM, | ||
| CodeGenFileType CGFT, | ||
| raw_pwrite_stream &OS) const { | ||
| if (Info.PreCodeGenCallback) | ||
| return Info.PreCodeGenCallback(M, TM, CGFT, OS); | ||
| return false; | ||
| } | ||
|
|
||
| private: | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about the other places in-tree that load plugins: Flang, clang-linker-wrapper, libLTO, opt and lld? Do they need adjustment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need no, they continue to work just fine.
opt doesn't call and lld doesn't directly call back-ends.