[PATCH] D97924: [LangRef] clarify the semantics of nocapture

[Johannes Doerfert via Phabricator via llvm-commits]

jdoerfert added a comment.

In D97924#2611088 <https://reviews.llvm.org/D97924#2611088>, @nlopes wrote:

> We just need a definition of capture that is precise enough for the kind of escape analysis we want to implement. The case above seems a bit artificial.

Artificial, sure. Though, OpenMP GPU runtime as very similar situations, e.g., internal globals we see all uses.
That said, I agree with your statement we want to "optimize" this in two steps, nevertheless, conceptually I'd hope we would not define this a capture even if the global is not demoted to stack.

Some thoughts on other topics discussed here:

> dynamic vs static semantic

I doubt we can explain the examples I presented reasonably in a purely static manner. It's a dynamic property for me.

> nocapture & trackable
>
>    f(nocapture p) {
>    p2 = load glb
>    ret p2
>   }

I do not think the example should cause UB if p == p2. The argument that we want to keep "track of" p and `nocapture` is a way to ensure we can is in principle valid, however, if p2 can be p, we either lost track of it already or we should have tracked the uses of `glb`. Either way, `nocapture` helps us to keep track of the argument without the UB requirement here while it is up to the caller to keep track of the value being passed before the call. Said differently, `nocapture` uses do not require you to track additional value/location but `nocapture` is not an object property and other uses/locations have to be tracked separately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97924