Add the missing one-to-n structural type conversion pattern for the
scf.for operation.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Fix issue where operations created after the signature conversion were generated
inside the loop body rather than after the loop.
Thanks a lot for this addition! Looks good modulo the minor comments.
The build failure seems unrelated. I guess rebasing should make them pass.
mlir/lib/Dialect/SCF/Transforms/OneToNTypeConversion.cpp | ||
---|---|---|
160 | Nit: I'd prefer if the comment used the full line length and did not have a line break in between the two sentences. | |
190 | I think that this guard (and the scope around it) isn't necessary. | |
202 | Nit: Please order alphabetically. |
mlir/lib/Dialect/SCF/Transforms/OneToNTypeConversion.cpp | ||
---|---|---|
190 | With the current implementation of applySignatureConversion, the guard is necessary since the rewriter is always left focused on the block that the signature conversion was applied to. That will results in unrealized_conversion_casts being generated in the loop body for the loop outputs when the rewriter.replaceOp is called. It is not clear to me that is the most desirable behavior of applySignatureConversion, but I opted not to change it, as it is difficult to tell who might be depending on that particular behavior. |
mlir/lib/Dialect/SCF/Transforms/OneToNTypeConversion.cpp | ||
---|---|---|
190 | I can't reproduce this: I have removed guard on my machine and the tests still pass. (Also, I don't see any unrealized cast if I run the pass outside of lit.) |
mlir/lib/Dialect/SCF/Transforms/OneToNTypeConversion.cpp | ||
---|---|---|
190 | Is it possible you did not have the @for_tuple_ops test? I added it later after discovering this specific issue. When I remove the insertion guard, that test fails for me with the following IR (note the pair of make_tuple ops after the scf.yield): "func.func"() <{function_type = (i1) -> i1, sym_name = "for_tuple_ops"}> ({ ^bb0(%arg0: i1): %0 = "arith.constant"() <{value = 0 : index}> : () -> index %1 = "arith.constant"() <{value = 1 : index}> : () -> index %2 = "arith.constant"() <{value = 10 : index}> : () -> index %3 = "scf.for"(%0, %2, %1, %arg0) ({ ^bb0(%arg1: index, %arg2: i1): %7 = "test.make_tuple"() : () -> tuple<> %8 = "test.make_tuple"(%7, %arg2) : (tuple<>, i1) -> tuple<tuple<>, i1> %9 = "test.op"(%8) : (tuple<tuple<>, i1>) -> tuple<tuple<>, i1> %10 = "test.get_tuple_element"(%9) <{index = 0 : i32}> : (tuple<tuple<>, i1>) -> tuple<> %11 = "test.get_tuple_element"(%9) <{index = 1 : i32}> : (tuple<tuple<>, i1>) -> i1 "scf.yield"(%11) : (i1) -> () %12 = "test.make_tuple"() : () -> tuple<> %13 = "test.make_tuple"(%12, %3) : (tuple<>, i1) -> tuple<tuple<>, i1> }) : (index, index, index, i1) -> i1 %4 = "test.op"(%13) : (tuple<tuple<>, i1>) -> tuple<tuple<>, i1> %5 = "test.get_tuple_element"(%4) <{index = 0 : i32}> : (tuple<tuple<>, i1>) -> tuple<> %6 = "test.get_tuple_element"(%4) <{index = 1 : i32}> : (tuple<tuple<>, i1>) -> i1 "func.return"(%6) : (i1) -> () }) : () -> () } Those tuple operations should be placed after the for loop, rather than in the loop body. |
mlir/lib/Dialect/SCF/Transforms/OneToNTypeConversion.cpp | ||
---|---|---|
190 | I just double-checked: the test is there in my version -- and it does not fail without the guard. This isn't a huge deal, I guess. I am rather trying to reproduce the error in order to know how to improve the API. This behavior isn't expected and I guess I'd prefer for it not to require the guard in the usual case. (But for that, a test case were it doesn't behave that way would be helpful.) |
mlir/lib/Dialect/SCF/Transforms/OneToNTypeConversion.cpp | ||
---|---|---|
190 | I agree that the guard is a bit ugly, though I'm now more concerned about the seeming non-determinism between systems. I'll try uploading a patch with the guard removed and see if the pre-merge testing experiences the same issue I'm seeing. |
mlir/lib/Dialect/SCF/Transforms/OneToNTypeConversion.cpp | ||
---|---|---|
190 | I'm able to reproduce this issue on the pre-merge testing machines as well: |
mlir/lib/Dialect/SCF/Transforms/OneToNTypeConversion.cpp | ||
---|---|---|
190 | Thanks a lot for helping me investigate and for your patience! I was finally able to reproduce the behavior you observed (I think my build set-up was broken and I ran the wrong version) and to submit a fix: https://reviews.llvm.org/D154684. |
mlir/lib/Dialect/SCF/Transforms/OneToNTypeConversion.cpp | ||
---|---|---|
190 | The fix has landed, so rebasing should make the insertion guard here unnecessary. Thanks for raising the issue and bearing with me! |
@ingomueller-net Would you be able to submit the change. I do not have commit access.
Nit: I'd prefer if the comment used the full line length and did not have a line break in between the two sentences.