-
Notifications
You must be signed in to change notification settings - Fork 11k
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
[flang] de-duplicate AbstractResult pass #88867
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 |
---|---|---|
|
@@ -19,6 +19,7 @@ | |
#include "flang/Optimizer/Transforms/Passes.h" | ||
#include "llvm/Passes/OptimizationLevel.h" | ||
#include "llvm/Support/CommandLine.h" | ||
#include <type_traits> | ||
|
||
#define DisableOption(DOName, DOOption, DODescription) \ | ||
static llvm::cl::opt<bool> disable##DOName("disable-" DOOption, \ | ||
|
@@ -86,6 +87,31 @@ DisableOption(BoxedProcedureRewrite, "boxed-procedure-rewrite", | |
DisableOption(ExternalNameConversion, "external-name-interop", | ||
"convert names with external convention"); | ||
|
||
// TODO: remove once these are used for non-codegen passes | ||
#if !defined(FLANG_EXCLUDE_CODEGEN) | ||
using PassConstructor = std::function<std::unique_ptr<mlir::Pass>()>; | ||
tblah marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
template <typename OP> | ||
void addNestedPassToOps(mlir::PassManager &pm, PassConstructor ctor) { | ||
pm.addNestedPass<OP>(ctor()); | ||
} | ||
|
||
template <typename OP, typename... OPS, | ||
typename = std::enable_if_t<sizeof...(OPS) != 0>> | ||
void addNestedPassToOps(mlir::PassManager &pm, PassConstructor ctor) { | ||
addNestedPassToOps<OP>(pm, ctor); | ||
addNestedPassToOps<OPS...>(pm, ctor); | ||
} | ||
|
||
void addNestedPassToAllTopLevelOperations( | ||
mlir::PassManager &pm, PassConstructor ctor) { | ||
// TODO: add more operations that might need full lowering support | ||
// any operations also need to be added to fir::isa_toplevel | ||
addNestedPassToOps<mlir::func::FuncOp, mlir::omp::DeclareReductionOp, | ||
fir::GlobalOp>(pm, ctor); | ||
} | ||
#endif | ||
|
||
/// Generic for adding a pass to the pass manager if it is not disabled. | ||
template <typename F> | ||
void addPassConditionally( | ||
|
@@ -304,9 +330,7 @@ inline void createDebugPasses( | |
inline void createDefaultFIRCodeGenPassPipeline( | ||
mlir::PassManager &pm, MLIRToLLVMPassPipelineConfig config) { | ||
fir::addBoxedProcedurePass(pm); | ||
pm.addNestedPass<mlir::func::FuncOp>( | ||
fir::createAbstractResultOnFuncOptPass()); | ||
pm.addNestedPass<fir::GlobalOp>(fir::createAbstractResultOnGlobalOptPass()); | ||
addNestedPassToAllTopLevelOperations(pm, fir::createAbstractResultOptPass); | ||
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. Wouldn't using pm.nestAny(fir::createAbstractResultOptPass()) work? It seems to me that the using both Although, maybe the reverse is better from a conceptual point of view: canScheduleOn could be removed from the pass definition. There is no conceptual aspects of the pass that restrict it from running on any operation that may contain FIR calls I think, so it would make sense to me that the pipeline is the only place describing which top level operations needs to be translated here. 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. Thanks for review. I think the idea is that We have to implement 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.
In that case, I think it should be runnable on any op (the ReturnOp handling prevents that currently since you noticed it does not work on ModuleOp).
You do not need to in that case because AbstractResultOptPass actually inherits from So all in all, I am OK with your patch, it is an improvement, and it could be further improved by modifying the 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. Ahh I had missunderstood the tablegen change I made. I thought it made it inherit mlir::Pass, but you are right it is Thanks for explaining. I will see if I can create a nested pass pipeline inside the AbstractResultPass so that even when run on a module it behaves the same way as if you ran the old function and global passes. And I agree that the |
||
fir::addCodeGenRewritePass(pm); | ||
fir::addTargetRewritePass(pm); | ||
fir::addExternalNameConversionPass(pm, config.Underscoring); | ||
|
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.
This declaration can be auto-generated by TableGen by just removing the
let constructor = ...
line in the Pass entry. This will also automatically create an overload that can be constructed with the option object.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.
Thanks for this. I'll update the flang passes as I go along