<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">I'm not convinced that this is the way to go either. </div>
<div class=""><br class="">
</div>
<div class="">The notion of capture is still mostly an implementation detail of LLVM's alias analysis. It boils down to the fact whether the current implementation can keep track of all aliases of the pointer. We do have a section about pointer capture in the
LangRef (<a href="https://llvm.org/docs/LangRef.html#pointer-capture" class="">https://llvm.org/docs/LangRef.html#pointer-capture</a>), but it is specific to nocapture attribute on calls. It is defined by explicitly prohibiting specific operations on the pointer
within the function. </div>
<div class=""><br class="">
</div>
<div class="">I find proposed definition of nocapture_store metadata rather vague. From
<a href="https://reviews.llvm.org/D93189" class="">https://reviews.llvm.org/D93189</a>:</div>
<div class="">"the pointer stored is not captured in the sense that all uses of the pointer are explicitly marked otherwise and the storing can be ignored during capture analysis".</div>
<div class=""><br class="">
</div>
<div class="">This definition makes lax use of the term "capture". This term is only defined in the LangRef with respect to pointers and calls.</div>
<div class="">It refers to "capture analysis" which is an implementation detail of LLVM's alias analysis and not defined anywhere. </div>
<div class="">It also says "all uses of the pointer are explicitly marked otherwise". The proposed way of marking the uses is the nocapture_use operand bundle. So, essentially, the only way a "nocapture stored" pointer can be used today is in a call (this is
because today we can only attach operand bundles to calls and invokes). This is very limiting. </div>
<div class=""><br class="">
</div>
<div class="">This limitation can be lifted if we introduce operand bundles on arbitrary instructions. Assuming we do that, the definition above suggests that we need to mark *all* uses of the "nocapture stored" pointers. It means every single instruction,
including geps, bitcasts, etc. need to bear this operand bundle. This looks verbose and fragile. Every transform now needs to preserve this marking, otherwise risking a miscompile.</div>
<div class=""><br class="">
</div>
<div class="">Speaking of possible alternatives, we can probably define "nocapture storage" as memory that doesn't outlive the scope of the current function (it should probably have some other name, because it doesn't rely on term capture). Having this property
we can extend capture tracking with flow-insensitive analysis to keep track of pointers stored into "nocapture storage".</div>
<div class=""><br class="">
</div>
<div class="">The other alternative that was suggested previously was to explicitly mark aliasing properties in the IR similarly to (or using) noalias and alias.scope metadata.</div>
<div class=""><br class="">
</div>
<div class="">Artur</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Nov 8, 2021, at 2:53 PM, Johannes Doerfert via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">NOTE: This was originally send in January 2021 [0]. The rational is still the same,<br class="">
there are two different proposed solutions based on the conversations back then.<br class="">
<br class="">
TL;DR: A pointer stored in memory is not necessarily captured, let's add a way to express this in IR.<br class="">
<br class="">
<br class="">
--- Rational (copied mostly from [0]) ---<br class="">
<br class="">
This would solve PR48475.<br class="">
<br class="">
Runtime functions, as well as regular functions, might require a pointer<br class="">
to be passed in memory even though the memory is simply a means to pass<br class="">
(multiple) arguments. That is, the indirection through memory is only<br class="">
used on the call edge and not otherwise relevant. However, such pointers<br class="">
are currently assumed to escape as soon as they are stored in memory<br class="">
even if the callee only reloads them and use them in a "non-escaping" way.<br class="">
Generally, storing a pointer might not cause it to escape if all "uses of<br class="">
the memory" it is stored to all have the "nocapture" property. While the<br class="">
Attributor is aware of this and tries to determine all "copies" that the<br class="">
store created, other passes are not and frontends cannot provide this<br class="">
information for known APIs.<br class="">
<br class="">
To allow optimizations in the presence of pointers stored to memory we<br class="">
introduce *two* IR extensions:<br class="">
Option A) `!nocapture_store` metadata and `"nocapture_use"` operand<br class="">
bundle tags.<br class="">
Option B) `!nocapture_storage` metadata and `"nocapture_use"` operand<br class="">
bundle tags.<br class="">
Option A) is what was proposed in [0]. Option B) is slightly different and<br class="">
based on the discussions from [0] as well as a prototype patch [2].<br class="">
<br class="">
Semantics Option A)<br class="">
If a store of a pointer is tagged with `!nocapture_store` it guarantees that<br class="">
the pointer is not captured by this store. To ensure we still "account" for the<br class="">
uses of the pointer once it is reloaded we add the `"nocapture_use"` operand<br class="">
bundle tag with the pointer as argument to callees that will interact with the<br class="">
pointer loaded from memory.<br class="">
<br class="">
Semantics Option B)<br class="">
If a memory allocation is tagged with `!nocapture_storage` it guarantees that<br class="">
stores of a pointer to that memory are not capturing the pointer. To ensure<br class="">
we still "account" for the uses of the pointer once it is reloaded we add the<br class="">
`"nocapture_use"` operand bundle tag with the pointer as argument to callees<br class="">
that will interact with the pointer loaded from memory.<br class="">
The difference to Option B) is that we do not tag stores but allocations.<br class="">
<br class="">
<br class="">
--- Previous Discussion ---<br class="">
<br class="">
The discussion as part of [0] did evolve around a way to handle yet another use case,<br class="">
basically what happens if the reloads of the stored away pointer are (partially)<br class="">
exposed rather than hidden behind a runtime function interface. The short answer is:<br class="">
That is not supported by this RFC alone. The longer answer contains different possible<br class="">
extensions to this RFC that would allow us to support such use cases. That said, the<br class="">
runtime use case seems relevant enough to be handled first, especially since there is<br class="">
no frontend/pass right now (in LLVM) that would rely on any of the extended use cases.<br class="">
<br class="">
<br class="">
--- Proposal ---<br class="">
<br class="">
Resurrect [1], or make [2] into a proper patch.<br class="">
I still think [1] is the way to go as it is more generic and has less lookup cost.<br class="">
<br class="">
---<br class="">
<br class="">
~ Johannes<br class="">
<br class="">
<br class="">
[0] <a href="https://lists.llvm.org/pipermail/llvm-dev/2021-January/147664.html" class="">
https://lists.llvm.org/pipermail/llvm-dev/2021-January/147664.html</a><br class="">
[1] <a href="https://reviews.llvm.org/D93189" class="">https://reviews.llvm.org/D93189</a><br class="">
[2] <a href="https://reviews.llvm.org/D109749#3078176" class="">https://reviews.llvm.org/D109749#3078176</a><br class="">
<br class="">
<br class="">
-- <br class="">
───────────────────<br class="">
∽ Johannes (he/his)<br class="">
<br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>