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

[Nuno Lopes via Phabricator via llvm-commits]

nlopes added a comment.

> If we have an object which has not yet been captured passed to a nocapture argument of a function, we know that the object remains uncaptured after the call.  Additionally, we also know that the callee hasn't increased the number of locations in which references to the object can be observed after the call.  Thus, if the caller can precisely enumerate said set before the call, that said remains precise after the call completes.

You are hinting at a more dynamic semantics, while we're proposing a more syntactic one.
Consider this example:

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

According to your definition, this functions triggers UB if p2 == p, because it increases the number of observations of p. It's counter-intuitive to me that a function that doesn't touch its nocapture argument captures that argument.

Another case is this:

  f(nocapture p, q) {
    glb = g
  }

Similarly, this function would trigger UB if p == q. This contrasts with how other attributes work. For example, if a pointer is readonly we can't write through it, but we can still write to the object provided we have another non-readonly pointer to it.

We've been thinking along these lines:

- a function cannot return a pointer tagged as nocapture
- on return, the memory cannot have any nocapture-tagged pointer stored in captured objects, global objects, or objects passed as arguments

It's a more syntactic view than what you are proposing, but I think it's more in line with the other attributes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97924