Now that passes have support for running nested pipelines, the inliner can now allow for users to provide proper nested pipelines to use for optimization during inlining. This revision also changes the behavior of optimization during inlining to optimize before attempting to inline, which should lead to a more accurate cost model and prevents the need for users to schedule additional duplicate cleanup passes before/after the inliner that would already be run during inlining.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
I don't quite get why you have to keep a separate builder callback for the default pass manager and build it on demand and cache it on every new encountered op name, why not just relying on the client adding it to the opPipelines StringMapwith an empty key for instance?
mlir/include/mlir/Pass/AnalysisManager.h | ||
---|---|---|
315–316 | I'd explain that the operation has to be a transitive child: it can't be an arbitrary op | |
mlir/lib/Pass/Pass.cpp | ||
872–873 | Comment it out of sync |
Comment Actions
The problem is that, at present, a PassManager can't be constructed to run on any operation. It always requires the type of the operation that it is going to be scheduled on.
I'd explain that the operation has to be a transitive child: it can't be an arbitrary op