[PATCH] D94002: [LangRef] Make lifetime intrinsic's semantics consistent with StackColoring's comment

[Ralf via Phabricator via llvm-commits]

RalfJung added inline comments.


================
Comment at: llvm/docs/LangRef.rst:17871
+If ``ptr`` is a stack-allocated object and its offset is zero, the object is
+initially marked as dead.
+After '``llvm.lifetime.start``', the stack object that ``ptr`` points is marked
----------------
This sentence here is doing a lot of work. In particular, it makes the behavior of `alloca` *depend on the future of the current execution*, i.e. behavior depends on whether at some point in the future, a lifetime.start intrinsic is called on the resulting pointer. I think such acausal definitions are a mistake; they make it impossible to write an interpreter that just accurately executes LLVM IR and detects UB.

At the very least, the documentation of `alloca` should be adjusted to explicitly talk about this. Right now, the documentation of lifetime.start alters the behavior of another instruction, which is really surprising and will easily be missed.

Does LLVM correctly handle code like the following, which should not be UB even though there is an access to an alloca before the lifetime.start? (Imagine this to be LLVM IR code, and without "mustprogress")

```
x = alloca ...;
*x = 5;
while (true) {}
lifetime.start(x)
```


================
Comment at: llvm/docs/LangRef.rst:17885
+a stack object that is already alive, it simply fills all bytes of the object
+with ``poison``.
+
----------------
So when `ptr` is a pointer to a stack-allocated object at offset 4, then *all bytes* of the object, including the ones at offset 0-3, will become `poison`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94002/new/

https://reviews.llvm.org/D94002