Cleanup resource management and rename recursive matchers

This CL follows up on a memory leak issue related to SmallVector growth that
escapes the BumpPtrAllocator.
The fix is to properly use ArrayRef and placement new to define away the
issue.

The following renaming is also applied:
1. MLFunctionMatcher -> NestedPattern
2. MLFunctionMatches -> NestedMatch

As a consequence all allocations are now guaranteed to live on the BumpPtrAllocator.

PiperOrigin-RevId: 231047766

1 files changed, 3 insertions, 4 deletions

diff --git a/mlir/lib/Transforms/ComposeAffineMaps.cpp b/mlir/lib/Transforms/ComposeAffineMaps.cpp
index 3dc81a0d793..4752928d062 100644
--- a/mlir/lib/Transforms/ComposeAffineMaps.cpp
+++ b/mlir/lib/Transforms/ComposeAffineMaps.cpp
@@ -22,7 +22,7 @@
 //===----------------------------------------------------------------------===//
 
 #include "mlir/Analysis/AffineAnalysis.h"
-#include "mlir/Analysis/MLFunctionMatcher.h"
+#include "mlir/Analysis/NestedMatcher.h"
 #include "mlir/IR/AffineMap.h"
 #include "mlir/IR/Attributes.h"
 #include "mlir/IR/Builders.h"
@@ -49,7 +49,7 @@ struct ComposeAffineMaps : public FunctionPass {
   PassResult runOnFunction(Function *f) override;
 
   // Thread-safe RAII contexts local to pass, BumpPtrAllocator freed on exit.
-  MLFunctionMatcherContext MLContext;
+  NestedPatternContext MLContext;
 
   static char passID;
 };
@@ -74,8 +74,7 @@ PassResult ComposeAffineMaps::runOnFunction(Function *f) {
   auto apps = pattern.match(f);
   for (auto m : apps) {
     auto app = cast<OperationInst>(m.first)->cast<AffineApplyOp>();
-    SmallVector<Value *, 8> operands(app->getOperands().begin(),
-                                     app->getOperands().end());
+    SmallVector<Value *, 8> operands(app->getOperands());
     FuncBuilder b(m.first);
     auto newApp = makeComposedAffineApply(&b, app->getLoc(),
                                           app->getAffineMap(), operands);