================
@@ -4670,6 +4670,82 @@ 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 start of the lifetime of a variable produced by a
cir.alloca operation";
+ let description = [{
+ The `cir.lifetime.start` operation marks the beginning of the lifetime
+ of the storage 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 `cir.scope` is the operation that models the block scope of the C/C++
+ source. Once ClangIR is no longer structured, `cir.scope` can no longer
express
+ the lifetime of a local variable. This happens, for example, after
`FlattenCFG`,
+ where `cir.scope` regions are dissolved into plain basic blocks, or after
+ `HoistAllocas`, where an alloca is moved to the function entry so that its
+ position no longer reflects the scope it was declared in. In that form,
these
+ lifetime markers are what delimit the beginning and end of a variable's
+ lifetime.
+
+ The verifier requires `$ptr` to be produced by a `cir.alloca`. For the
+ lifetime to be meaningful, a matching `cir.lifetime.end` on the same
+ pointer should follow on every control-flow path. Note that, unlike LLVM
----------------
Lancern wrote:
```suggestion
pointer should follow on every control-flow path. This is different from
LLVM
```
https://github.com/llvm/llvm-project/pull/199599
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
