<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 28, 2021 at 8:15 AM Sameer Sahasrabuddhe <<a href="mailto:sameer@sbuddhe.net">sameer@sbuddhe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><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" target="_blank">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" target="_blank">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></div></div></div></blockquote><div><br></div><div>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?</div><div><br></div><div>Cheers,</div><div>Nicolai</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:10pt"><div> <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></div></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Lerne, wie die Welt wirklich ist,<br>aber vergiss niemals, wie sie sein sollte.</div></div>