[Mlir-commits] [mlir] [mlir][llvm] Improve alloca handling during inlining (PR #75961)
Tobias Gysi
llvmlistbot at llvm.org
Wed Dec 20 02:22:29 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 = ¤tOp->getParentRegion()->front();
+ break;
+ }
+ currentOp = parentOp;
+ }
----------------
gysit wrote:
Yes I agree there is no trait that guarantees we can hoist an alloca in the general case. Isolated from above guarantees that the value is visible. However, the region may have parallel semantics or other unknown semantics that makes hoisting invalid. We will solve the problem downstream.
https://github.com/llvm/llvm-project/pull/75961
More information about the Mlir-commits
mailing list