Insert ops replacing pad_tensor in front of the associated tansfer_write / insert_slice op. Otherwise we may end up with invalid ir if one of the remaining tansfer_write / insert_slice operands is defined after the pad_tensor op.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp | ||
---|---|---|
874 | it feels strange to have this right before a replace<> call can you please add a comment on the insertion point to explain why it is needed (since it is not a typical pattern in rewriting) | |
1020 | same request, add a comment on why this is here |
mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp | ||
---|---|---|
874 | Good point. The insertion point by default is after the matched operation AFAIK. Without setting the insertion point we would thus insert the new transfer operation right after the pad operation (the matched one). That means some of the transfer operands may be undefined / not dominating the use. For example, in the tests the newly created transfer op would be before the make_vector() and use its result. Will add a comment in the source! |
it feels strange to have this right before a replace<> call
is this because of the insertions in the parameter, or the subsequence replace? (bit hard to judge without running this to see output)
can you please add a comment on the insertion point to explain why it is needed (since it is not a typical pattern in rewriting)