[llvm-dev] convergent operations in OpenMP

[Sameer Sahasrabuddhe via llvm-dev]

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?

Sameer.