================
@@ -4670,6 +4670,62 @@ def CIR_StackRestoreOp : CIR_Op<"stackrestore"> {
let assemblyFormat = "$ptr attr-dict `:` qualified(type($ptr))";
}
+//===----------------------------------------------------------------------===//
+// LifetimeStartOp & LifetimeEndOp
+//===----------------------------------------------------------------------===//
+
+def CIR_LifetimeStartOp : CIR_Op<"lifetime.start"> {
+ let summary = "Marks the beginning of an alloca object's live range";
+ let description = [{
+ The `cir.lifetime.start` operation marks the beginning of the live range
+ of the memory region pointed to by `$ptr`. Between this operation and a
+ matching `cir.lifetime.end` on the same pointer, the underlying storage
+ is considered live; outside that range it is considered dead, and the
+ optimizer is free to reuse the storage for other purposes.
+
+ The verifier requires `$ptr` to be produced by a `cir.alloca`. For the
+ live range to be meaningful, a matching `cir.lifetime.end` on the same
+ pointer should follow on every control-flow path.
----------------
Lancern wrote:
LLVM actually allows an `llvm.lifetime.start` call without a matching
`llvm.lifetime.end` call:
> The stack object is marked as dead again when either
> [llvm.lifetime.end](https://llvm.org/docs/LangRef.html#int-lifeend) to the
> alloca/structured.alloca is executed *or the function returns*. [^1]
[^1]: https://llvm.org/docs/LangRef.html#int-lifestart
Should we mimic this design? I'm not sure whether the OGCG could emit code like
this.
https://github.com/llvm/llvm-project/pull/199599
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
