[Mlir-commits] [mlir] [mlir][memref] Promote buffers accessed via memref.copy (PR #232078)
Jianhui Li
llvmlistbot at llvm.org
Mon Oct 19 23:08:39 PDT 2026
================
@@ -162,7 +166,124 @@ Value mlir::memref::buildDynamicSubViewMask(OpBuilder &builder, Location loc,
return buildSubViewMask(builder, loc, subView);
}
+/// Produces the value that a `memref.copy` stores into a slot: reads `mem` at
+/// the origin into `vecType` with an identity map, marking a dimension
+/// in-bounds only when the memref extent is statically at least the vector
+/// extent.
+///
+/// The padding value does not affect the copy: both operands must have the same
+/// runtime shape. For a whole-buffer slot, the source covers the whole vector.
+/// For a dynamic-subview slot,
+/// `PromotableAliaserInterface::projectAliasValueToSlotValue` discards lanes
+/// outside the subview's extent with a masked select.
+static Value readMemRefAsVector(OpBuilder &builder, Location loc, Value mem,
----------------
Jianhui-Li wrote:
@banach-space Sounds good. I created a draft PR to understand what it takes to extend mem2reg. https://github.com/llvm/llvm-project/pull/233705
The changes look small. The trade-off is to ask mem2reg to give a special handling for mask transfer op through ownsEmbeddedBlockingUses() interface.
Does it looks reasonable to you? If it does, I can split it to two PRs (one to enhance the mem2reg interface, the other is to add masked transfer op support for PromotableMemOpInterface).
Also FYI: As I understand more about the masked transfer op (thanks for your explanation!), I believe that these two interfaces (isDyanmicSubViewSlot/buildDyanmicSubviewMask) can be removed. But will do it in a separate PR.
https://github.com/llvm/llvm-project/pull/232078
More information about the Mlir-commits
mailing list