[llvm-dev] convergent operations in OpenMP

[Nicolai Hähnle via llvm-dev]

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>