
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div>Resending to the correct list ...<br></div><div><br>Hi all, <br> <br>I've been working on making the "convergent" attribute be the default on <br>all functions and calls, along with changes to optimizations so that <br>there is no performance regression on CPU targets. <br> <br>The overall idea is as follows: <br> <br>1. Convergent operations are only affected by divergent branches. <br>2. Control flow optimizations should care about convergent operations <br> only if they occur in a context where the optimization affects <br> diverent branches. <br>3. CPU targets are single-threaded, and hence trivially, there are no <br> divergent branches. This is sufficient to ensure that optimizations <br> are never affected on CPU targets if they follow #2. <br> <br>See the following review for a discussion that sent us down this path: <br> <br><a href="https://reviews.llvm.org/D69498">https://reviews.llvm.org/D69498</a> <br> <br>My first attempt was to modify the Sink optimization, which currently <br>does not sink an operation if it is convergent. The change additionally <br>checks to see if divergent control flow is present to prevent sinking: <br> <br><a href="https://reviews.llvm.org/D106859">https://reviews.llvm.org/D106859</a> <br> <br>But this broke OpenMP lit tests like this one: <br> <br>openmp/tools/archer/tests/barrier/barrier.c <br> <br>The problem is that OpenMP builtins currently rely on the "convergent" <br>attribute to convey barrier semantics, even on CPU targets. I am <br>guessing that the actual implementation on a CPU will use other native <br>primitives like atomics. But it seems reasonable to say "convergent" and <br>expect it to mean exactly what it says, without relying on the <br>underlying implementation. <br> <br>But this means that the "convergent" property is environment-defined <br>rather than target-defined. If we go down that path, what would be the <br>correct way to say this in an LLVM module? Should "OpenMP" be an <br>environment in the target triple? Or something more general, that <br>conveys that this module depends on "convergent communication outside of <br>the memory model"? <br> <br>Sameer. <br></div></div><br></body></html>