This patch add the possibilities to create out-of-tree MIR passes. This is based on how IR out-of-tree passes work.
If this is something that could be upstreamed, I could factorize the code between the two system, as they are very similar!
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
As a side remark, I have tested this with an out of tree MIR pass that dump MIR, and it works well. Should I add this test within the test suite? I didn't find such test for the current out-of-tree IR system (but chances are I missed it!).
Could you add some documentation, probably in docs/MIRLangRef.rst? Also you lack a test case, probably in ./CodeGen/MIR/Generic/
Thanks Serge for the comments !
I added examples, a test that test these examples, and a mention of them in the documentation (not sure it's in the right place though!).
examples/OutOfTreeMIR/ModulePass/ModulePass.cpp | ||
---|---|---|
1 ↗ | (On Diff #230380) | Please add copyright information. |
examples/CMakeLists.txt | ||
---|---|---|
10 ↗ | (On Diff #230383) | Why don't you always build it? |
examples/OutOfTreeMIR/FunctionPass/CMakeLists.txt | ||
1 ↗ | (On Diff #230383) | based on ../lib/Transforms/Hello/CMakeLists.txt, you could pass BUILDTREE_ONLY as an extra flag |
lib/CodeGen/TargetPassConfig.cpp | ||
229 ↗ | (On Diff #230383) | This code is very similar to the legacy pass manager machinery, which is very different from the new PM one. Adding the feature here totally makes sense to me, but I'm unsure if the MIR passes management is going to be reworked just like IR passes was, @chandlerc ? |
examples/CMakeLists.txt | ||
---|---|---|
10 ↗ | (On Diff #230383) | Because I test them as out-of-tree passes. My understanding is that, if LLVM isn't built with shared libraries, or with "LINK_LLVM_DYLIB", I won't be able to build a shared library for the passes that llc would load. |
lib/CodeGen/TargetPassConfig.cpp | ||
---|---|---|
229 ↗ | (On Diff #230383) | @chandlerc any insights of what will happen with the MIR passes management? Does this patch conflict with any current refactoring on the subject? Thanks! |
- Update to monorepo and master
- Add forgotten RegisterMIRPasses.h
- Compile and test even in static mode
Any update on that? it's a great solution, filling in the gap with GCC, which enhances dynamic intervention even in RTL phase.
I think this can be utilized for many upgrades and platform adjustments.
RegisterMIRPasses uses the "old" mechanism using a static initializer to register passes. For some time now the llvm-project it trying to get rid of static initializers because of their problems (static initialization order fiasco, more difficult to use as a library, etc.) AFAIU, especially MLIR was designed to avoid static initializers from the ground up, e.g. to register a dialect one has to call e.g. registerAffinePasses explicitly instead of relying on static initializers. I feel the patch re-introduces what we were trying to avoid.
For LLVM, the new mechanism used for NPM is Passes/PassPlugin.h which use dlopen and dlsym to execute a defined entry-point (llvmGetPassPluginInfo).
clang-tidy: warning: invalid case style for variable 'EP_EnumSize' [readability-identifier-naming]
not useful