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

[Johannes Doerfert via Phabricator via llvm-commits]

jdoerfert added a comment.

I think we have to stick to a pointer-based definition not an object one. However, we should describe it holistically, which this patch does in parts.

The key idea is, IMO, that if I have a pointer `p` and I pass it as an argument to a function `f`, will any bits of `p` become "public knowledge" through the call.
That is, if I pick random bits for `p` (thereby eliminating aliases), would they be available after the call (to the executing thread or another thread).

This definition is born out of the use cases I know of for `nocapture` which basically ask if I can freely change the bits of the pointer without disturbing anything, e.g., move heap to stack.
One note: Most of the time, `nocapture` is really only interesting if you have a "noalias" (or function identified) pointer, that means, it is often useful at the call site, not inside the callee.

What I want to avoid (not to say this patch doesn't!) is to define temporary storage necessarily captures. For me "capturing" is making the bits available after the call, not the fact of storing it.
So if you have some memory not accessible by others, put your pointer in there, and then you take it out before you return, all is good. Some examples: https://clang.godbolt.org/z/P1d7rG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97924