llvm dev - Jul 2021 - convergent operations in OpenMP

Resending to the correct list ...


Hi all, 
 
I've been working on making the "convergent" attribute be the
default on
all functions and calls, along with changes to optimizations so that 
there is no performance regression on CPU targets. 
 
The overall idea is as follows: 
 
1. Convergent operations are only affected by divergent branches. 
2. Control flow optimizations should care about convergent operations 
 only if they occur in a context where the optimization affects 
 diverent branches. 
3. CPU targets are single-threaded, and hence trivially, there are no 
 divergent branches. This is sufficient to ensure that optimizations 
 are never affected on CPU targets if they follow #2. 
 
See the following review for a discussion that sent us down this path: 
 
https://reviews.llvm.org/D69498 
 
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. 
 
But this means that the "convergent" property is environment-defined 
rather than target-defined. If we go down that path, what would be the 
correct way to say this in an LLVM module? Should "OpenMP" be an 
environment in the target triple? Or something more general, that 
conveys that this module depends on "convergent communication outside of 
the memory model"? 
 
Sameer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210728/02f9d6ea/attachment.html>

On Wed, Jul 28, 2021 at 8:15 AM Sameer Sahasrabuddhe <sameer at
sbuddhe.net>
wrote:
> Resending to the correct list ...
>
> Hi all,
>
> I've been working on making the "convergent" attribute be the
default on
> all functions and calls, along with changes to optimizations so that
> there is no performance regression on CPU targets.
>
> The overall idea is as follows:
>
> 1. Convergent operations are only affected by divergent branches.
> 2. Control flow optimizations should care about convergent operations
> only if they occur in a context where the optimization affects
> diverent branches.
> 3. CPU targets are single-threaded, and hence trivially, there are no
> divergent branches. This is sufficient to ensure that optimizations
> are never affected on CPU targets if they follow #2.
>
> See the following review for a discussion that sent us down this path:
>
> https://reviews.llvm.org/D69498
>
> 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?

Cheers,
Nicolai



> But this means that the "convergent" property is
environment-defined
> rather than target-defined. If we go down that path, what would be the
> correct way to say this in an LLVM module? Should "OpenMP" be an
> environment in the target triple? Or something more general, that
> conveys that this module depends on "convergent communication outside
of
> the memory model"?
>
> Sameer.
>
>
-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210728/8834c775/attachment.html>