The ModuleOp is empty after applyPatternsAndFoldGreedily is called

MLIR
#1

I want to use the applyPatternsAndFoldGreedily function to change the Op in ModuleOp. but the ModuleOp is empty after applyPatternsAndFoldGreedily is called.

The code is like following

struct TestLowing: public mlir::OpRewritePattern<RingBufferOp>{
    TestLowing(mlir::MLIRContext *context)
      : OpRewritePattern<RingBufferOp>(context, /*benefit=*/1) {}
    
    mlir::LogicalResult matchAndRewrite(RingBufferOp op,
                mlir::PatternRewriter &rewriter) const override {
        return success();
    }
};


struct PostOperationPass:
    public PassWrapper<SliceModePostOperationPass, OperationPass<ModuleOp>>{
        MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID(PostOperationPass)

    void getDependentDialects(DialectRegistry &registry) const override {
        registry.insert<MyDialect>();
    }
    void runOnOperation() final;
};

void PostOperationPass::runOnOperation(){
    RewritePatternSet pattern_set(&getContext());
    pattern_set.add<TestLowing>(&getContext());

    auto patterns = FrozenRewritePatternSet(std::move(pattern_set));
    GreedyRewriteConfig config;
    config.useTopDownTraversal = true;
    config.enableRegionSimplification = false;
    config.maxIterations = 10;
    auto operation = getOperation();
    operation.dump(); // the ModuleOp has content.
    auto result = applyPatternsAndFoldGreedily(operation, patterns, config);
    if(failed(result)){
        signalPassFailure();
    }
    operation.dump(); // the ModuleOp is empty.
}

is there something wrong when I use the applyPatternsAndFoldGreedily function?

#2

What does the content of the module look like? Do you have only side-effect-free operations that can all be folded away?
If you remove your pattern from the set what happens?

In general running with -debug should show you step by step what happens.

#3

Thank you for you reply.
The module is like following

module {
  %0 = "pulsar.param"() {params = dense<0> : tensor<16x32x3x3xi8>} : () -> tensor<16x32x3x3xi8>
  %1 = "pulsar.ringbuffer"() {buffer_size = 64 : i32, delay = 0 : i32} : () -> tensor<16x64x64xi8>
  %2 = "pulsar.data"() {shape = dense<[16, 64, 64]> : tensor<3xi64>} : () -> tensor<16x64x64xi8>
  "pulsar.set"(%2, %1) {begin = 0 : i32, end = 64 : i32} : (tensor<16x64x64xi8>, tensor<16x64x64xi8>) -> ()
  %3 = "pulsar.view"(%1) {begin = 0 : i32, end = 64 : i32} : (tensor<16x64x64xi8>) -> tensor<16x64x64xi8>
  %4 = "pulsar.conv"(%3, %0) {mode = 0 : i32, padding_left = true, padding_right = true} : (tensor<16x64x64xi8>, tensor<16x32x3x3xi8>) -> tensor<32x64x64xi8>
}

after pattern match and rewrite, it will be

module {
  %0 = "pulsar.param"() {params = dense<0> : tensor<16x32x3x3xi8>} : () -> tensor<16x32x3x3xi8>
  %1 = "pulsar.data"() {shape = dense<[16, 64, 64]> : tensor<3xi64>} : () -> tensor<16x64x64xi8>
  %2 = "pulsar.conv"(%1, %0) {mode = 0 : i32, padding_left = true, padding_right = true} : (tensor<16x64x64xi8>, tensor<16x32x3x3xi8>) -> tensor<32x64x64xi8>
}

but the module is empty after applyPatternsAndFoldGreedily is called, even I do nothing in matchAndRewrite or just remove the pattern.

#4

applyPatternsAndFoldGreedily also performs DCE, so if your ops are considered side effect free and aren’t returning anywhere, they are probably being DCE’ed. I’ve never seen ops directly in a module, so I don’t know if that affects this situation.

#5

Nothing is using the results of your pulsar.conv operation: this is covered by what I described earlier as Do you have only side-effect-free operations that can all be folded away??

If you were to add an operation, let’s say pulsar.print(%2) that wouldn’t be side-effect free, this should all work.

Also in general we use another container inside the module, such as a function or a graph, or a program: there will have a way to express input/output (or argument/results).

#6

Thank you for you reply!

I set the NoSideEffect mark on the pulsar.conv op.

The problem is solverd after I remove the NoSideEffect mark.

#7

While that will solve the symptoms here, be aware that this isn’t a principled / correct fix.

2 Likes
#8

:ok_hand:，I will change it into a correct fix in formal development