[llvm-dev] convergent operations in OpenMP

[Johannes Doerfert via llvm-dev]

On 7/28/21 4:24 AM, Sameer Sahasrabuddhe wrote:
> Nicolai Hähnle writes:
>
>> On Wed, Jul 28, 2021 at 8:15 AM Sameer Sahasrabuddhe <sameer at sbuddhe.net>
>>> My first attempt was to modify the Sink optimization, which currently
>>> does not sink an operation if it is convergent. The change additionally
>>> checks to see if divergent control flow is present to prevent sinking:
>>>
>>> https://reviews.llvm.org/D106859
>>>
>>> But this broke OpenMP lit tests like this one:
>>>
>>> openmp/tools/archer/tests/barrier/barrier.c
>>>
>>> The problem is that OpenMP builtins currently rely on the "convergent"
>>> attribute to convey barrier semantics, even on CPU targets. I am
>>> guessing that the actual implementation on a CPU will use other native
>>> primitives like atomics. But it seems reasonable to say "convergent" and
>>> expect it to mean exactly what it says, without relying on the
>>> underlying implementation.
>>>
>> Out of curiosity, since I'm not familiar with the whole OpenMP setup: what
>> does the IR currently look like at the point where the test gets broken?
> Good question! I am equally unfamiliar with the OpenMP flow. The IR that
> I get from "clang -emit-llvm ..." contains calls to runtime functions
> and I don't know how to link those into the IR. I am currently working
> on the simple fact that my review request is showing failures with a
> bunch of "libarcher" tests.
>
> But now it seems I am getting failures locally with or without my
> change. So, false alarm, maybe?

Libarcher tests fail for all phab reviews for a while. That has nothing
to do with your patch.

As far as I can tell there is no use of `convergent` on the CPU,
or at least it would not mean much.

~ Johannes


> Sameer.