[llvm] [IR] LangRef: document behavior of double-lifetime.start (PR #184296)

[Ralf Jung via llvm-commits]

RalfJung wrote:

> Yes, but that was for heap allocations. It would poison all the data on each start.

Ah, that seems largely orthogonal to what I was thinking about when writing this PR. I'd be entirely fine with making `lifetime.{start,end}` be UB for non-`alloca` allocations.

> I don't have a preference for any of the possible options here

Actually I take that back -- we settled the relevant parts of the semantics for the last IR in the Rust frontend (MIR) a while ago relying on redundant `lifetime.start` *not* being UB. (Resetting the value is fine.) So making it UB would be a breaking change for us that could be non-trivial to deal with. I don't remember the full decision process for that any more; IIRC it was a combination of two factors:
- The initial MIR we generate sometimes doesn't have a `StorageDead` in loops, leading to redundant `StorageLive`. (Those MIR ops translate to `lifetime.end` and `lifetime.start`, respectively.)
- On more than one occasion, MIR optimizations would rearrange `Storage*` in a way that introduces redundant `StorageLive`.

So, it turned out to be a non-trivial hassle to avoid redundant `StorageLive`, and there seemed to be no upside to making them UB, so we decided they should be allowed.


Recently @Amanieu proposed adjustments to how we track local variable liveness in MIR, and for code where a local variable is conditionally initialized in an `if` and then later unconditionally overwritten, the plan is to just emit a `lifetime.start` both times to ensure the local variable is live when it needs to be (but not earlier). This is still work-in-progress.

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