Skip to content

[MLIR][Transforms] Fix Mem2Reg removal order to respect dominance #68687

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 10, 2023

Conversation

Dinistro
Copy link
Contributor

This commit fixes a bug in the Mem2Reg operation erasure order. Replacing the topological order with a dominance based order ensures that no operation is removed before all its uses have been replaced. Additionally, the reliance on the DenseMap key order was eliminated by switching to a MapVector, that gives a deterministic iteration order.

Example:

%ptr = alloca ...
...
%val0 = %load %ptr ... // LOAD0
store %val0 %ptr ...
%val1 = load %ptr ... // LOAD1

When promoting the slot backing %ptr, it can happen that the LOAD0 was cleaned before LOAD1. This results in all uses of LOAD0 being replaced by its reaching definition, before LOAD1's result is replaced by LOAD0's result. The subsequent erasure of LOAD0 can thus not succeed, as it has remaining usages.

This commit fixes a bug in the Mem2Reg operation erasure order.
Replacing the topological order with a dominance based order ensures
that no operation is removed before all its uses have been replaced.
Additionally, the reliance on the `DenseMap` key order was eliminated by
switching to a `MapVector`, that gives a deterministic iteration order.

Example:

```
%ptr = alloca ...
...
%val0 = %load %ptr ... // LOAD0
store %val0 %ptr ...
%val1 = load %ptr ... // LOAD1
````

When promoting the slot backing %ptr, it can happen that the LOAD0
was cleaned before LOAD1. This results in all uses of LOAD0 being
replaced by its reaching definition, before LOAD1's result is replaced
by LOAD0's result. The subsequent erasure of LOAD0 can thus not
succeed, as it has remaining usages.
@Dinistro Dinistro requested review from gysit and Moxinilian October 10, 2023 11:15
@llvmbot llvmbot added mlir:core MLIR Core Infrastructure mlir:llvm mlir labels Oct 10, 2023
@llvmbot
Copy link
Member

llvmbot commented Oct 10, 2023

@llvm/pr-subscribers-mlir-llvm
@llvm/pr-subscribers-mlir

@llvm/pr-subscribers-mlir-core

Author: Christian Ulmann (Dinistro)

Changes

This commit fixes a bug in the Mem2Reg operation erasure order. Replacing the topological order with a dominance based order ensures that no operation is removed before all its uses have been replaced. Additionally, the reliance on the DenseMap key order was eliminated by switching to a MapVector, that gives a deterministic iteration order.

Example:

%ptr = alloca ...
...
%val0 = %load %ptr ... // LOAD0
store %val0 %ptr ...
%val1 = load %ptr ... // LOAD1

When promoting the slot backing %ptr, it can happen that the LOAD0 was cleaned before LOAD1. This results in all uses of LOAD0 being replaced by its reaching definition, before LOAD1's result is replaced by LOAD0's result. The subsequent erasure of LOAD0 can thus not succeed, as it has remaining usages.


Full diff: https://github.com/llvm/llvm-project/pull/68687.diff

2 Files Affected:

  • (modified) mlir/lib/Transforms/Mem2Reg.cpp (+16-12)
  • (modified) mlir/test/Dialect/LLVMIR/mem2reg.mlir (+13)
diff --git a/mlir/lib/Transforms/Mem2Reg.cpp b/mlir/lib/Transforms/Mem2Reg.cpp
index 65de25dd2f32663..0591d0541290d74 100644
--- a/mlir/lib/Transforms/Mem2Reg.cpp
+++ b/mlir/lib/Transforms/Mem2Reg.cpp
@@ -106,7 +106,7 @@ struct MemorySlotPromotionInfo {
   /// its uses, it is because the defining ops of the blocking uses requested
   /// it. The defining ops therefore must also have blocking uses or be the
   /// starting point of the bloccking uses.
-  DenseMap<Operation *, SmallPtrSet<OpOperand *, 4>> userToBlockingUses;
+  llvm::MapVector<Operation *, SmallPtrSet<OpOperand *, 4>> userToBlockingUses;
 };
 
 /// Computes information for basic slot promotion. This will check that direct
@@ -129,8 +129,9 @@ class MemorySlotPromotionAnalyzer {
   /// uses (typically, removing its users because it will delete itself to
   /// resolve its own blocking uses). This will fail if one of the transitive
   /// users cannot remove a requested use, and should prevent promotion.
-  LogicalResult computeBlockingUses(
-      DenseMap<Operation *, SmallPtrSet<OpOperand *, 4>> &userToBlockingUses);
+  LogicalResult
+  computeBlockingUses(llvm::MapVector<Operation *, SmallPtrSet<OpOperand *, 4>>
+                          &userToBlockingUses);
 
   /// Computes in which blocks the value stored in the slot is actually used,
   /// meaning blocks leading to a load. This method uses `definingBlocks`, the
@@ -233,7 +234,8 @@ Value MemorySlotPromoter::getLazyDefaultValue() {
 }
 
 LogicalResult MemorySlotPromotionAnalyzer::computeBlockingUses(
-    DenseMap<Operation *, SmallPtrSet<OpOperand *, 4>> &userToBlockingUses) {
+    llvm::MapVector<Operation *, SmallPtrSet<OpOperand *, 4>>
+        &userToBlockingUses) {
   // The promotion of an operation may require the promotion of further
   // operations (typically, removing operations that use an operation that must
   // delete itself). We thus need to start from the use of the slot pointer and
@@ -243,7 +245,7 @@ LogicalResult MemorySlotPromotionAnalyzer::computeBlockingUses(
   // use it.
   for (OpOperand &use : slot.ptr.getUses()) {
     SmallPtrSet<OpOperand *, 4> &blockingUses =
-        userToBlockingUses.getOrInsertDefault(use.getOwner());
+        userToBlockingUses[use.getOwner()];
     blockingUses.insert(&use);
   }
 
@@ -281,7 +283,7 @@ LogicalResult MemorySlotPromotionAnalyzer::computeBlockingUses(
       assert(llvm::is_contained(user->getResults(), blockingUse->get()));
 
       SmallPtrSetImpl<OpOperand *> &newUserBlockingUseSet =
-          userToBlockingUses.getOrInsertDefault(blockingUse->getOwner());
+          userToBlockingUses[blockingUse->getOwner()];
       newUserBlockingUseSet.insert(blockingUse);
     }
   }
@@ -516,14 +518,16 @@ void MemorySlotPromoter::computeReachingDefInRegion(Region *region,
 }
 
 void MemorySlotPromoter::removeBlockingUses() {
-  llvm::SetVector<Operation *> usersToRemoveUses;
-  for (auto &user : llvm::make_first_range(info.userToBlockingUses))
-    usersToRemoveUses.insert(user);
-  SetVector<Operation *> sortedUsersToRemoveUses =
-      mlir::topologicalSort(usersToRemoveUses);
+  llvm::SmallVector<Operation *> usersToRemoveUses(
+      llvm::make_first_range(info.userToBlockingUses));
+  // The uses need to be traversed in *reverse dominance* order to ensure that
+  // transitive replacements are performed correctly.
+  llvm::sort(usersToRemoveUses, [&](Operation *a, Operation *b) {
+    return dominance.properlyDominates(b, a);
+  });
 
   llvm::SmallVector<Operation *> toErase;
-  for (Operation *toPromote : llvm::reverse(sortedUsersToRemoveUses)) {
+  for (Operation *toPromote : usersToRemoveUses) {
     if (auto toPromoteMemOp = dyn_cast<PromotableMemOpInterface>(toPromote)) {
       Value reachingDef = reachingDefs.lookup(toPromoteMemOp);
       // If no reaching definition is known, this use is outside the reach of
diff --git a/mlir/test/Dialect/LLVMIR/mem2reg.mlir b/mlir/test/Dialect/LLVMIR/mem2reg.mlir
index 30ba459d07a49f3..ced9afffdc043d4 100644
--- a/mlir/test/Dialect/LLVMIR/mem2reg.mlir
+++ b/mlir/test/Dialect/LLVMIR/mem2reg.mlir
@@ -683,3 +683,16 @@ llvm.func @no_inner_alloca_promotion(%arg: i64) -> i64 {
   // CHECK: llvm.return %[[RES]] : i64
   llvm.return %2 : i64
 }
+
+// -----
+
+// CHECK-LABEL: @transitive_reaching_def
+llvm.func @transitive_reaching_def() -> !llvm.ptr {
+  %0 = llvm.mlir.constant(1 : i32) : i32
+  // CHECK-NOT: alloca
+  %3 = llvm.alloca %0 x !llvm.ptr {alignment = 8 : i64} : (i32) -> !llvm.ptr
+  %6 = llvm.load %3 {alignment = 8 : i64} : !llvm.ptr -> !llvm.ptr
+  llvm.store %6, %3 {alignment = 8 : i64} : !llvm.ptr, !llvm.ptr
+  %7 = llvm.load %3 {alignment = 8 : i64} : !llvm.ptr -> !llvm.ptr
+  llvm.return %7 : !llvm.ptr
+}

Copy link
Contributor

@gysit gysit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM modulo nit comments.

@Dinistro Dinistro merged commit be81f42 into llvm:main Oct 10, 2023
@Dinistro Dinistro deleted the fix-mem2reg-removal-order branch October 10, 2023 12:07
bviyer added a commit to bviyer/llvm-project that referenced this pull request Oct 10, 2023
`include/c++/v1/__debug_utils/strict_weak_ordering_check.h:52: assertion !__comp(*(__first + __b), *(__first + __a)) failed: Your comparator is not a valid strict-weak ordering`

I think it is due to an invalid sort().

Revert "[MLIR][Transforms] Fix Mem2Reg removal order to respect dominance (llvm#68687)"

This reverts commit be81f42.
d0k pushed a commit that referenced this pull request Oct 10, 2023
…ance (#68687)" (#68732)

This commit causes the following issue with sanitizers:

`include/c++/v1/__debug_utils/strict_weak_ordering_check.h:52: assertion
!__comp(*(__first + __b), *(__first + __a)) failed: Your comparator is
not a valid strict-weak ordering`

probably due to an invalid sort().

Revert "[MLIR][Transforms] Fix Mem2Reg removal order to respect
dominance (#68687)"

This reverts commit be81f42.
@Dinistro Dinistro restored the fix-mem2reg-removal-order branch October 11, 2023 07:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mlir:core MLIR Core Infrastructure mlir:llvm mlir
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants