[Mlir-commits] [mlir] [MLIR][Vector] Generalize DropUnitDimFromElementwiseOps to non leading / trailing dimensions. (PR #98455)

Hugo Trachino llvmlistbot at llvm.org
Thu Jul 11 09:53:30 PDT 2024


================
@@ -1622,7 +1622,33 @@ struct ChainedReduction final : OpRewritePattern<vector::ReductionOp> {
   }
 };
 
-/// For vectors with either leading or trailing unit dim, replaces:
+// Helper function dropping unit non-scalable dimension from a VectorType.
+// Scalable unit dimensions are not dropped. Folding such dimensions would
+// require "shifting" the scalable flag onto some other fixed-width dim (e.g.
+// vector<[1]x4xf32> -> vector<[4]xf32>). This could be implemented in the
+// future.
+static VectorType dropNonScalableUnitDimFromType(VectorType inVecTy) {
+  auto inVecShape = inVecTy.getShape();
+  SmallVector<int64_t> newShape;
+  SmallVector<bool> newScalableDims;
+  for (auto [dim, isScalable] :
+       llvm::zip_equal(inVecShape, inVecTy.getScalableDims())) {
+    if (dim == 1 && !isScalable)
+      continue;
+
+    newShape.push_back(dim);
+    newScalableDims.push_back(isScalable);
+  }
+  // All dims have been dropped, we need to return a legal shape for VectorType.
----------------
nujaa wrote:

Yes. I saw some instances essentially with data transfer memory shape ops (extract, broadcast, ...). Do you think the solution rather allow elementwise op to support vector<f32> ?

It was indeed an issue coming from IREE yet, it was reproduced with LLVM

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


More information about the Mlir-commits mailing list