[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