[Mlir-commits] [mlir] [mlir][linalg] Add pattern to bubble-up pack through expand shape op (PR #93529)

[Adam Siemieniuk]

================
@@ -694,6 +696,107 @@ bubbleUpPackOpThroughCollapseShape(tensor::CollapseShapeOp collapseOp,
   return success();
 }
 
+/// Project dimsPos to their collapsed positions in the reassocIndices.
+///
+/// For example, given dimsPos [0, 1, 2, 4], and matching reassocIndices
+/// [[0], [1, 2], [3], [4]], it returns [0, 1, 1, 3]. Because for pos 0,
+/// the reassoc dim [0] is 0. For pos 1 and 2, the reassoc dim in pos
+/// [1, 2] is 1. And for pos 4, the reassoc dim [4] is 3.
+static SmallVector<int64_t>
+projectDimsPosIntoReassocPos(ArrayRef<int64_t> dimsPos,
+                             ArrayRef<ReassociationIndices> reassocIndices) {
+  SmallVector<int64_t> projectedPos;
+
+  // Map each dimension to the position of corresponding reassociation index.
+  for (auto pos : dimsPos) {
+    for (auto [idx, indices] : llvm::enumerate(reassocIndices)) {
+      // If the dimension is present in the current indices group, the group
+      // position within the reassociation map is the desired projected
+      // dimension position.
+      if (llvm::any_of(indices,
+                       [&](int64_t expandDim) { return expandDim == pos; })) {
+        projectedPos.push_back(idx);
+        break;
+      }
+    }
+  }
+  assert(projectedPos.size() == dimsPos.size() && "Invalid dim pos projection");
+
+  return projectedPos;
+}
+
+/// Bubble up pack op through expand shape op.
----------------
adam-smnk wrote:

Lit at least gives me guarantee that examples there are verified and valid.
I won't trust a random IR in a comment to grasp the functionality. Either, I take it at face value and "don't care", or look deeper i.e., read the logic and/or look at tests.

Perhaps, my different opinion comes from the clarity of the name itself. It's not a complex transform that requires deep explanation as it could be as long as or longer than the logic itself. The transform's name is already succinct and conveys the message.

> Can you elaborate why it will only get quickly outdated?

It's a more general statement. The simple case of `expand(pack) -> pack(expand)` stays valid. But the examples in this file are really verbose. The finer details like ops' arguments or input/output shapes might stay relevant or not.

When IR syntax or semantics change, random comments like that are least likely to get updated. In fact, expand_shape has already changed with addition of `output_shape`. It doesn't matter here but still the example is already outdated.

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