llvm dev - Jul 2021 - convergent operations in OpenMP

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.

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.