The ForOp::build ensures that there is a block terminator which is great for
the default use case when there are no iter_args and loop.for returns no
results. In non-zero results case we always need to call replaceOpWithNewOp
which is not the nicest thing in the world. We can stop inserting YieldOp when
iter_args is non-empty. IfOp::build already behaves similarly.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/LoopOps/LoopOps.cpp | ||
---|---|---|
51 | This looks like the constructed op will be invalid by construction if iterArgs is non-empty, due to the missing terminator. It may be fine as long as it is clear from the documentation that the caller is supposed to fix that. Alternatively, you can still create a terminator that returns iterArgs, which would give you a valid region, but will probably defy the purpose of this patch. |
Commit summary please - even if it's a couple of lines. It's not clear from the title why the 'for' block won't be missing a terminator.
@bondhugula Updated the summary. Thanks!
mlir/lib/Dialect/LoopOps/LoopOps.cpp | ||
---|---|---|
51 | I updated the documentation in LoopOps.td. The option with removing 'ensureTermitor' even for the default case without results did not work quite well, since it breaks many users and adds boilerplate code to insert YieldOp, since mostly, ForOp is used without `iter_args' and I think it makes sense to leave this use case with implicit insertion of terminator. |
I've been told we have the same for IfOp, so this behavior is at least consistent within the dialect.
This looks like the constructed op will be invalid by construction if iterArgs is non-empty, due to the missing terminator. It may be fine as long as it is clear from the documentation that the caller is supposed to fix that. Alternatively, you can still create a terminator that returns iterArgs, which would give you a valid region, but will probably defy the purpose of this patch.