[llvm-dev] [RFC] Introduce the `!nocapture` metadata and "nocapture_use" operand bundle

[Johannes Doerfert via llvm-dev]

Hi Jameson,

thanks for the input.

On 1/8/21 12:25 PM, Jameson Nash wrote:
> Hey Johannes,
>
>  From my recollection of past conversations with you, in the example with
> `foo`, shouldn't there be a `pthread_join` call also represented in the
> documentation, so that the lifetime of the child call is shown to not
> escape the scope of the parent stack frame?

Absolutely, or we would need to allocate `p` on the heap. The
underlying idea is not impacted by this though.



>
> For the !nocapture/nocapture_use optimizations, what is the intended
> semantics in the presence of interprocedural analysis, such as inlining? It
> sounds like the !nocapture is tied to the lifetime of the alloca, but the
> last use of the value loaded is always, necessarily, going to come after
> the last use of the alloca (to load the value), and thus seems insufficient
> to cover the lifetime of the uses of that stored pointer.

Good point. I think we have a conservatively correct inliner:
   https://godbolt.org/z/79YYPP

That is, if you see operand bundles, don't inline. This is, in general,
necessary. Not to say we cannot teach the inliner how to handle some
of them. The most important use cases for the new features would be to
bridge API boundaries through which we cannot inline though. If we have
the definition of the callee we could inline, or (internalize and) do
argument promotion. However, if we have runtime calls we can't. Things
like the OpenMP reduction API take all the pointers that will be reduced
into, thereby capturing them. We cannot inline or promote the passed
struct without static linking of the library, which is often not a (good)
option.

Does this make sense?

~ Johannes


>
> On Thu, Jan 7, 2021 at 7:21 PM Johannes Doerfert via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> TL;DR: A pointer stored in memory is not necessarily captured, let's add
>> a way to express this.
>>
>> Phab: https://reviews.llvm.org/D93189
>>
>> --- Commit Message / Rational ---
>>
>> Runtime functions, as well as regular functions, might require a pointer
>> to be passed in memory even though the memory is simply a means to pass
>> (multiple) arguments. That is, the indirection through memory is only
>> used on the call edge and not otherwise relevant. However, such pointers
>> are currently assumed to escape as soon as they are stored in memory
>> even if the callee only reloads them and use them in a "non-escaping" way.
>> Generally, storing a pointer might not cause it to escape if all "uses of
>>    the memory" it is stored to all have the "nocapture" property.
>>
>> To allow optimizations in the presence of pointers stored to memory we
>> introduce two new IR extensions. `!nocapture` metadata on stores and
>> "nocapture_use" operand bundles for call(base) instructions. The former
>> ensures that the store can be ignored for the purpose of escape
>> analysis. The latter indicates that a call is using a pointer value
>> but not capturing it. This is important as the call might still read
>> or write the pointer and since the passing of the pointer through
>> memory is not considered "capturing" with the "nocapture" metadata,
>> we need to otherwise indicate the potential read/write.
>>
>> As an example use case where we can deduce `!nocapture` metadata,
>> consider the following code:
>>
>> ```
>> struct Payload {
>>     int *a;
>>     double *b;
>> };
>>
>> int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
>>                       void *(*start_routine) (void *), void *arg);
>>
>> int use(double);
>>
>> void fn(void *v) {
>>     Payload *p = (Payload*)(v);
>>     // Load the pointers from the payload and then dereference them,
>>     // this will not capture the pointers.
>>     int *a = p->a;
>>     double *b = p->b;
>>     *a = use(*b);
>> }
>>
>> void foo(int *a, double *b) {
>>     Payload p = {a, b};
>>     pthread_create(..., &fn, &p);
>> }
>> ```
>>
>> Given the usage of the payload struct in `fn` we can conclude neither
>> `a` nor `b` in are captured in `foo`, however we could not express this
>> fact "locally" before. That is, we can deduce and annotate it for the
>> arguments `a` and `b` but only since there is no other use (later on).
>> Similarly, if the callee would not be known, we were not able to
>> describe the "nocapture" behavior of the API.
>>
>> A follow up patch will introduce `!nocapture` metadata to stores
>> generated during OpenMP lowering. This will, among other things, fix
>> PR48475. I generally expect us to find more APIs that could benefit from
>> the annotation in addition to the deduction we can do if we see the callee.
>>
>> ---
>>
>> As always, feedback is welcome. Feel free to look at the phab patch as
>> well.
>>
>> Thanks,
>>     Johannes
>>
>>
>> --
>> ──────────
>> ∽ Johannes
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>