[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