[PATCH] D101701: [nofree] Refine concurrency requirements

[Nicolai Hähnle via Phabricator via llvm-commits]

nhaehnle added a comment.

> Finally, we started to track threads explicitly already, partially using domain knowledge, which allows us to reason about the interaction between threads 
> (https://reviews.llvm.org/D106397#C2702144NL1110). So even in the presence of synchronizations (atomics, barriers, etc), we can use other attributes
> (argmemonly, nofree, ...) and such thread tracking to make useful deductions. This is not possible if we interleave the `argmemonly/nofree/...` semantics
> with `nosync`. The above optimization is a real thing for a very common scenario on GPUs and also CPUs:
>
>   run_in_parallel {
>     if (threadid == 0)
>       effect();
>     barrier();
>   
>     ... parallel stuff
>   
>     if (threadid == 0)
>       effect();
>     barrier();
>    ...
>   }

I've been staring at this for quite some time now and I don't understand how it relates to this discussion. Can you be more explicit about which functions here have e.g. argmemonly but not nosync, and how that is used in an optimization?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101701