Pick the right result type when folding transpose op into a read
Details
Diff Detail
Event Timeline
LGTM
mlir/test/Conversion/VectorToGPU/vector-to-mma-ops.mlir | ||
---|---|---|
440 | What is this test testing differently from the one immediately above? I only notice the differing shapes. |
mlir/test/Conversion/VectorToGPU/vector-to-mma-ops.mlir | ||
---|---|---|
440 | Yes, only the shapes are different, that's what exposes the bug since the pattern was mixing source and destination types. |
IMO, the accessor name could use some improvements---it's very confusing and error-prone just being getVectorType(); making it something like getSrcVectorType() would make it far easier to avoid pitfalls. At least for me, I need to read the impl to double check what it means by just getVectorType().
+1 getVectorType() isn't by itself informative of its function, although with careful thought I could have avoided introducing this error. Also in this case it seems that none of the conversion tests were testing non-square matrices which was also a point of brittleness.
To close the loop: https://reviews.llvm.org/D144159 landed for improving the accessor methods.
What is this test testing differently from the one immediately above? I only notice the differing shapes.