[Mlir-commits] [mlir] [mlir][Vector] Promote buffers accessed via dynamic subviews and memref.copy (PR #217793)

[Andrzej Warzyński]

================
@@ -36,11 +41,24 @@ using namespace mlir::vector;
 //  Utilities
 //===----------------------------------------------------------------------===//
 
-/// Returns whether `xferOp` accesses exactly the whole contents of `slot`, so
-/// it can act as a plain whole-buffer load/store during Mem2Reg.
+/// Returns whether `xferOp` can be promoted to a load/store of `slot`'s vector
+/// value. This requires that the transfer's sole use of the slot is as its
+/// base, the transferred vector type equals `slot.valueType`, the indices are
+/// all zero (origin), and the permutation map is the identity.
+///
+/// Partial accesses through dynamic subviews or with mask operands are
+/// reconstructed with `arith.select` during promotion.
+///
+/// For a dynamic subview, the aliaser masks writes to preserve the parent value
+/// outside the subview's extent. Reads are masked here because they need the
+/// transfer's padding operand, which the aliaser does not have.
+///
+/// A transfer's mask operand is combined with the subview mask using
+/// `arith.andi` for reads. For writes, `getStored` applies it with a separate
+/// `arith.select` to preserve inactive lanes.
----------------
banach-space wrote:

This comment, to some extent, duplicates the top file comment:
```cpp
// Transfers must meet the criteria in `isPromotableTransfer`: their vector type
// must match the slot's value type, their indices must be zero, and their
// permutation map must be the identity. A read uses the slot's current value;
// a write defines its next value. For transfers with a mask operand or through
// a dynamic subview, `arith.select` supplies padding for inactive read lanes
// and preserves the previous value for inactive write lanes.
```

Also, the purpose of this method is to provide an answer to the following question (based on function name0:
* "Is this xfer Op promotable?"

I wouldn't go into the details of promotion (and how it's implemented) - that's more suitable for `removeBlockingUses`, no? Also, "isPromotableTransfer" tells us what's supported ATM - are there any obvious TODOs to consider? Are there any cases that will be impossible to support? 

It would be great to provide some indication. Thanks!

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