The TestGreedyFusionPass runs a pass pipeline using the module, but is
declared as a FunctionPass. Instead, just define the pass as a
ModulePass.
Details
- Reviewers
nicolasvasilache
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
mlir/test/lib/Transforms/TestLinalgFusionTransforms.cpp | ||
---|---|---|
189 | This looks likes a different behavior than before in how it'll repeat the nested pipeline multiple times per function even if only a single function gets a fusion. Is this really needed? | |
194 | Actually, why are we even doing this? Can we just remove all these passes and keep this pass dedicated to fuseLinalgOpsGreedily alone? | |
197 | Please use the dynamic pass pipeline: we should not run nested pipeline this way: https://mlir.llvm.org/docs/PassManagement/#dynamic-pass-pipelines | |
201 | I don't quite get why you can't run this on the current function instead? |
mlir/test/lib/Transforms/TestLinalgFusionTransforms.cpp | ||
---|---|---|
189 | Ah your right. Not really needed I think, but at the least need to move the while loop here to encompass the pipeline | |
201 | I think loop invariant code motion is a ModulePass? Is it valid to take the parent module of a pass labeled as a FunctionPass? Just using the funcOp here threw an error that it was running a module pass on a function pass. |
mlir/test/lib/Transforms/TestLinalgFusionTransforms.cpp | ||
---|---|---|
201 | LICM is even more generic: it is an Operation pass. It can be scheduled on a FuncOp or on a spv.func, or a gpu.module! If you can model after it here that'd be ideal! |
mlir/test/lib/Transforms/TestLinalgFusionTransforms.cpp | ||
---|---|---|
194 | Ping on this comment: can we remove this please? |
This looks likes a different behavior than before in how it'll repeat the nested pipeline multiple times per function even if only a single function gets a fusion. Is this really needed?