[PATCH] D101701: [nofree] Refine concurrency requirements

[Nuno Lopes via Phabricator via llvm-commits]

nlopes added a comment.

In D101701#2746949 <https://reviews.llvm.org/D101701#2746949>, @jdoerfert wrote:

> In D101701#2746841 <https://reviews.llvm.org/D101701#2746841>, @nlopes wrote:
>
>> @jdoerfert a function that syncs with another thread may not free anything itself and the other thread may not free anything either.
>> If you require an optimization to have nofree + nosync in a call to preserve dereferenceability then you can't optimize this case.
>
> I disagree, and I think this is the conceptual differences we have here.
>
> If one does only look at a function in isolation then I agree, `nofree` alone is not sufficient to make statements about all call sites and arguments.
> However, if you look at a call site of a `nofree` function the situation is different because you have context information about the arguments.
>
> Let's go back to my last example:
>
>   a = malloc
>   b = malloc
>   unknown(a);                  // no attributes 0-> escapes
>   nofree_nocapture_only(a, b); // `nofree`, `nocapture` on args
>
> I know that at the end of this sequence `b` has not been freed, even though there is no `nosync` in sight.
> I can also derive `nofree` for `nofree_nocapture_only` without worrying about atomics, for example.
> (Here is the sequence in action with heap2stack kicking in for b: https://godbolt.org/z/hjYrhaEvW)
>
> So, with `nofree` and `nosync` being completely separated, as it was in the very beginning, you can:
>
> 1. Optimize even if only one is present, given additional call site information.
> 2. Derive `nofree` even if `nosync` is not present.

Your examples are around nofree arguments, not nofree functions, which is what this patch is about.
nofree in functions is useful for pointers that are *not* passed as argument, like this:

  f(i8* %p) {
    load %p  ; implies it's dereferenceable
    call @g() nofree
    ; is %p still dereferenceable or not?
  }

This patch states that yes, %p is still dereferenceable after the call to @g as it's tagged with nofree. That's it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101701