[Mlir-commits] [mlir] [MLIR] Refactor DCE helper to expose worklist entry-point, and use this helper in CSE (PR #195636)

lonely eagle llvmlistbot at llvm.org
Mon May 4 07:19:13 PDT 2026


================
@@ -510,6 +510,74 @@ LogicalResult mlir::runRegionDCE(RewriterBase &rewriter,
   return deleteDeadness(rewriter, regions, liveMap);
 }
 
+int64_t mlir::eliminateTriviallyDeadOps(
+    RewriterBase &rewriter, Region &region, SmallVector<Operation *> &worklist,
+    DenseSet<Operation *> &visited, function_ref<void(Operation *)> preErase) {
+  LDBG(2) << "Initial worklist size: " << worklist.size();
+  int64_t numErased = 0;
+  while (!worklist.empty()) {
+    Operation *op = worklist.pop_back_val();
+    LDBG(2) << "Popped operation from worklist: "
+            << OpWithFlags(op, OpPrintingFlags().skipRegions());
+    /// Erase each operand to drop its use count before checking its defining
+    /// op: by the time we call isOpTriviallyDead on defOp, the
+    /// about-to-be-erased `op` is no longer counted as a user. Only
+    /// actually-dead ops enter the worklist.
+    ///
+    /// Walk nested operations as well because erasing `op` also implicitly
+    /// erases every operation nested under it and therefore drops their operand
+    /// uses.
+    op->walk([&](Operation *erasedOp) {
+      LDBG(3) << "Processing operands of operation erased: "
+              << OpWithFlags(erasedOp, OpPrintingFlags().skipRegions());
+      for (OpOperand &opOperand : erasedOp->getOpOperands()) {
+        Operation *defOp = opOperand.get().getDefiningOp();
+        if (!defOp) {
+          LDBG(4) << "Skipping operand #" << opOperand.getOperandNumber()
+                  << ": value has no defining operation";
+          continue;
+        }
+        if (defOp->getParentRegion() != &region) {
----------------
linuxlonelyeagle wrote:

I believe this check is unnecessary here, and the `region` parameter in `eliminateTriviallyDeadOps` is also redundant. If an op within a parent region were to be deleted, I'm afraid it might trigger an assertion in `ScopeHashtableScope`. That said, for the scope of this PR, I'm fine with keeping it as is.

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


More information about the Mlir-commits mailing list