[Mlir-commits] [mlir] [mlir][reducer] Add eraseAllOpsInRegion function to reduction-tree pass (PR #185892)

[lonely eagle]

================
@@ -145,19 +145,59 @@ static LogicalResult findOptimal(ModuleOp module, Region &region,
   return success();
 }
 
+/// This function attempts to erase all operations within the region currently
+/// being processed.
+static LogicalResult eraseAllOpsInRegion(ModuleOp module, Region &region,
+                                         const Tester &test) {
+  std::pair<Tester::Interestingness, size_t> initStatus =
+      test.isInteresting(module);
+
+  // While exploring the reduction tree, we always branch from an interesting
+  // node. Thus the root node must be interesting.
+  if (initStatus.first != Tester::Interestingness::True)
+    return module.emitWarning() << "uninterested module will not be reduced";
+  llvm::SpecificBumpPtrAllocator<ReductionNode> allocator;
+
+  // Setting the ranges to {{0, 0}} will result in the deletion of all ops
+  // within the region.
+  std::vector<ReductionNode::Range> ranges{{0, 0}};
+  ReductionNode *root = allocator.Allocate();
+  new (root) ReductionNode(nullptr, ranges, allocator);
----------------
linuxlonelyeagle wrote:

> if you know the reason this convention is used in the other parts of mlir-reduce.

If you're wondering why, you can take a look here.
https://github.com/llvm/llvm-project/blob/98ccac607a9ff044ec7d024e119bc975eb03ed4c/mlir/lib/Reducer/ReductionNode.cpp#L54

I’ve already considered this point. Since this PR doesn't call generateNewVariants, using stack allocation is reasonable here. Additionally, it should reduce syscall overhead (though I don't believe that's the primary benefit).

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