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

Nuno Lopes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 9 03:08:25 PST 2021


nlopes added a comment.

In D97924#2611453 <https://reviews.llvm.org/D97924#2611453>, @reames wrote:

> In D97924#2607261 <https://reviews.llvm.org/D97924#2607261>, @nlopes wrote:
>
>> 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.
>
> I agree, this is slightly counter intuitive.  I think it's also fundamentally necessary.

Can you expand why you think this is fundamental?
This semantics makes it very hard for an analysis to tag a parameter as nocapture. if a function stores a pointer to memory or returns a pointer it may be capturing any of the parameters, who knows.

More fundamentally, for optimization I think we only care about 2 cases:

- An object hasn't escaped
- An object escaped

The number of references to an escaped object doesn't matter. What we care about is when it flips from non-escaped to escaped.

What are the uses of nocapture information? It's used when traversing a function and analyze call sites. We want to know if a given locally-allocated object can be modified by a callee. If not, we can do all sorts of store forwarding, know that the object is still alive, etc.
So if a pointer is already escaped, we gain no information about the existence of further escapes. What we want is the flip. Hence I don't see how the semantics above are useful for this purpose.

If we have a function with 2 arguments;

   f(p, q) {
      g = p
  }

We want to be able to say that q doesn't escape regardless of whether p=q or not. Otherwise I feel we will never be able to infer this noescape attribute.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97924



More information about the llvm-commits mailing list