[Mlir-commits] [mlir] [mlir][llvm] Improve alloca handling during inlining (PR #75961)

Tobias Gysi llvmlistbot at llvm.org
Wed Dec 20 01:42:14 PST 2023


================
@@ -50,11 +50,29 @@ static bool hasLifetimeMarkers(LLVM::AllocaOp allocaOp) {
 static void
 handleInlinedAllocas(Operation *call,
                      iterator_range<Region::iterator> inlinedBlocks) {
+  // The traversal's objective is to locate the entry block of the closest call
+  // site ancestor that has the automatic allocation scope trait. In pure LLVM
+  // dialect programs, this is the LLVM function containing the call site.
+  // However, mixed dialect programs may have other allocation scopes.
+  assert(call->getParentWithTrait<OpTrait::AutomaticAllocationScope>() &&
+         "expected call site to be in an automatic allocation scope");
+  Block *allocaScopeEntryBlock = nullptr;
+  Operation *currentOp = call;
+  while (Operation *parentOp = currentOp->getParentOp()) {
+    if (parentOp->hasTrait<OpTrait::AutomaticAllocationScope>()) {
+      allocaScopeEntryBlock = &currentOp->getParentRegion()->front();
+      break;
+    }
+    currentOp = parentOp;
+  }
----------------
gysit wrote:

I would assume that an operation that is closed from above also has the automatic allocation scope trait? I can definitely add more checks the question is a bit if this is a problem we should rather solve downstream?  There can always be an operation with unknown semantics and being conservative here may make more sense (aka closing this revision)?

WDYT?

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


More information about the Mlir-commits mailing list