[Mlir-commits] [mlir] Fix unsupported transpose ops for scalable vectors in LowerVectorTransfer (PR #86163)

Benjamin Maxwell llvmlistbot at llvm.org
Fri Mar 22 02:49:16 PDT 2024


================
@@ -41,6 +41,23 @@ func.func @permutation_with_mask_scalable(%2: memref<?x?xf32>, %dim_1: index, %d
   return %1 : vector<8x[4]x2xf32>
 }
 
+// CHECK-LABEL:   func.func @permutation_with_mask_transfer_write_scalable(
+// CHECK-SAME:                                                             %[[ARG_0:.*]]: vector<4x[8]xi16>,
+// CHECK-SAME:                                                             %[[ARG_1:.*]]: memref<1x4x?x1x1x1x1xi16>,
+// CHECK-SAME:                                                             %[[MASK:.*]]: vector<4x[8]xi1>) {
+// CHECK:           %[[C0:.*]] = arith.constant 0 : index
+// CHECK:           %[[BCAST:.*]] = vector.broadcast %[[ARG_0]] : vector<4x[8]xi16> to vector<1x1x1x1x4x[8]xi16>
+// CHECK:           vector.transfer_write %[[BCAST]], %[[ARG_1]]{{\[}}%[[C0]], %[[C0]], %[[C0]], %[[C0]], %[[C0]], %[[C0]], %[[C0]]] {in_bounds = [true, true, true, true, true, true], permutation_map = #map} : vector<1x1x1x1x4x[8]xi16>, memref<1x4x?x1x1x1x1xi16>
----------------
MacDue wrote:

Is this transform generally correct? I see that this will probably do the correct thing despite the mismatched `memref` and `vector` types here, but surely these transposes exist for a reason so simply removing them for all scalable cases seems strange. 

For example, does the right thing happen if the `permutation_map` map actually permutes the order of dimensions, or if the indices on the `transfer_write` are non-zero?

In either case I think a few more test cases are needed :)

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


More information about the Mlir-commits mailing list