[Mlir-commits] [mlir] [mlir][vector] Account for vector.mask in transfer RAW/WAW checks (PR #228328)

[llvmlistbot at llvm.org]

================
@@ -2039,6 +2058,27 @@ func.func @store_to_load_tensor_broadcast(%arg0 : tensor<4x4xf32>,
 
 // -----
 
+// Same as above, but the read is under vector.mask: its masked-off lanes get
+// the padding value, so it must not become a broadcast of the stored vector.
+// CHECK-LABEL: func @negative_store_to_load_tensor_broadcast_region_masked
+//       CHECK:   vector.transfer_write
+//       CHECK:   %[[R:.*]] = vector.mask %{{.*}} { vector.transfer_read
+//   CHECK-NOT:   vector.broadcast
+//       CHECK:   return %[[R]] : vector<4x2x6xf32>
+func.func @negative_store_to_load_tensor_broadcast_region_masked(%arg0 : tensor<4x4xf32>,
+  %v0 : vector<4x2xf32>, %mask : vector<4x2xi1>) -> vector<4x2x6xf32> {
----------------
Vaisman wrote:

Yes. The last result of `(d0, d1) -> (d0, d1, 0)` is a broadcast dimension.
`inferTransferOpMaskType` drops it and the expected mask type is `vector<4x2xi1>`.
The `vector.mask` verifier checks this through `TransferReadOp::getExpectedMaskType()`.
With `vector<4x2x6xi1>` it reports "expects a 'vector<4x2xi1>' mask for the maskable operation".

https://github.com/llvm/llvm-project/pull/228328