[llvm-dev] convergent operations in OpenMP

[Sameer Sahasrabuddhe via llvm-dev]

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>