[Mlir-commits] [mlir] [mlir][bufferization] handle exit aliases in buffer-loop-hoisting (PR #226951)

Matteo Di Iorio llvmlistbot at llvm.org
Sat Oct 3 08:06:36 PDT 2026


================
@@ -371,14 +423,16 @@ struct BufferAllocationLoopHoistingState : BufferAllocationHoistingStateBase {
     return dependencyBlock ? dependencyBlock : nullptr;
   }
 
-  /// Returns true if the given operation represents a loop with sequential
-  /// execution semantics and one of the aliases caused the
-  /// `aliasDominatorBlock` to be "above" the block of the given loop operation.
-  /// If this is the case, it indicates that the allocation is passed via a back
-  /// edge.
+  /// Returns true if the allocation can be moved across the given loop.
   bool isLegalPlacement(Operation *op) {
-    return isSequentialLoop(op) &&
-           !dominators->dominates(aliasDominatorBlock, op->getBlock());
+    if (!isSequentialLoop(op))
+      return false;
+    if (!dominators->dominates(aliasDominatorBlock, op->getBlock()))
+      return true;
+    auto loop = dyn_cast<scf::WhileOp>(op);
+    if (!loop || !allocValue.getDefiningOp<memref::AllocOp>())
----------------
splicer3 wrote:

Essentially only `memref.alloc` is allowed here. That is because I found that `memref.realloc` also passes the loop-hoisting interface check. Hoisting it could move it before a store to its source in `before`, so the store would end up using the old memref after the realloc. The forward alias checks on the result don’t cover that use.

I think an explicit extension to `memref.alloca` could be harmless, but just dropping this check would also allow that `memref.realloc` case.

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


More information about the Mlir-commits mailing list