[Mlir-commits] [mlir] [MLIR][Mem2Reg] Add support for region control flow and SCF (PR #185036)

llvmlistbot at llvm.org llvmlistbot at llvm.org
Mon Mar 9 07:45:15 PDT 2026


================
@@ -430,13 +480,30 @@ MemorySlotPromotionAnalyzer::computeInfo() {
   // promotion to happen. These operations need to resolve some of their uses,
   // either by rewiring them or simply deleting themselves. If any of them
   // cannot find a way to resolve their blocking uses, we abort the promotion.
-  if (failed(computeBlockingUses(info.userToBlockingUses)))
+  // We also compute at this stage the regions that will be analyzed for
+  // reaching definition information.
+  if (failed(
+          computeBlockingUses(info.userToBlockingUses, info.regionsToPromote)))
     return {};
 
+  // Compute the blocks containing a store for each region, either directly or
+  // inherited from a nested region. As a side effect, `definingBlocks` contains
+  // all regions with at least one store.
+  DenseMap<Region *, SmallPtrSet<Block *, 16>> definingBlocks;
+  for (Operation *user : slot.ptr.getUsers())
+    if (auto storeOp = dyn_cast<PromotableMemOpInterface>(user))
+      if (storeOp.storesTo(slot))
+        definingBlocks[user->getParentRegion()].insert(user->getBlock());
+  for (auto &[region, regionInfo] : info.regionsToPromote)
+    if (regionInfo.hasValueStores)
+      definingBlocks[region->getParentRegion()].insert(
+          region->getParentOp()->getBlock());
----------------
tdegioanni-nvidia wrote:

`info.regionsToPromote` contains all regions to promote, so it contains the parent which will or may have been processed already. At the end of the day the whole chain is included, in the current version of the code.

That `info.regionsToPromote` contains all regions to promote can be observed by looking at the `visitRegions` lambda in `computeBlockingUses`.

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


More information about the Mlir-commits mailing list