This is an archive of the discontinued LLVM Phabricator instance.

[mlir] check whether region and block visitors are interrupted
ClosedPublic

Authored by ashay-github on Jul 13 2022, 7:13 PM.

Details

Summary

The visitor functions for Region and Block types did not always
check the value returned by recursive calls. This caused the top-level
visitor invocation to return WalkResult::advance() even if one or more
recursive invocations returned WalkResult::interrupt(). This patch
fixes the problem by check if any recursive call is interrupted, and if
so, return WalkResult::interrupt().

Diff Detail

Event Timeline

ashay-github created this revision.Jul 13 2022, 7:13 PM
ashay-github requested review of this revision.Jul 13 2022, 7:13 PM

It seems Phabricator didn't send out an email when I created the patch. Pinging folks to see if it helps.

@jurahul @rriddle

Thanks for the contribution! It looks good to me.

This patch doesn't add unit tests since our test framework
(TestGenericIRVisitorInterruptPass) invokes visitor functions for
operations but not for regions and blocks.

I think it's important that we test this. Would it possible to add a new visitor for regions and blocks?

ashay-github edited the summary of this revision. (Show Details)

Added tests for region and block visitors.

ashay-github added a comment.EditedJul 15 2022, 11:32 AM

I think it's important that we test this. Would it possible to add a new visitor for regions and blocks?

Thanks, that makes sense. I've added visitor functions for regions and blocks. However, BlockArguments cannot have attributes (which we use to decide whether to interrupt the walk), so the visitor function for blocks skips iterating over its argument.

dcaballe accepted this revision.Jul 15 2022, 1:52 PM

LGTM, thanks!

This revision is now accepted and ready to land.Jul 15 2022, 1:52 PM
rriddle added inline comments.Jul 15 2022, 5:12 PM
mlir/test/lib/IR/TestVisitorsGeneric.cpp
134–135

Same comment here as below.

166–167
168–169

This part doesn't really make sense, result.getDefiningOp() is just going to give you op again.

@rriddle My apologies! The fix is in this patch: https://reviews.llvm.org/D129913.