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

[Philip Reames via Phabricator via llvm-commits]

reames added a comment.

Now having read the text, and responding to the review.

The definition you're using appears to be in terms of the set of locations which can possibly refer to the object.   The problem is that if any element of that set is itself captured, then your object is captured.  This is the root confusion which made me realize we need to have a global definition of capture which isn't purely set based.

Reading through your definition, there's a subtlety to the nocapture argument attribute which is tricky.  The attribute doesn't simply state that the callee doesn't contain a capturing operation (using the candidate definitions from previously linked document), it also says that pointer isn't propagated into any non-capturing, but unknown to the caller additional location.  That's an important detail, and not one we want to loose.

I think we can combine the global definition of capture (as per the previously linked document) and your set based formalism.  Let me take a shot.

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.

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97924