<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 28, 2021 at 7:03 AM Johannes Doerfert via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
On 7/28/21 4:24 AM, Sameer Sahasrabuddhe wrote:<br>
> Nicolai Hähnle writes:<br>
><br>
>> On Wed, Jul 28, 2021 at 8:15 AM Sameer Sahasrabuddhe <<a href="mailto:sameer@sbuddhe.net" target="_blank">sameer@sbuddhe.net</a>><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" rel="noreferrer" 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>
>>><br>
>> Out of curiosity, since I'm not familiar with the whole OpenMP setup: what<br>
>> does the IR currently look like at the point where the test gets broken?<br>
> Good question! I am equally unfamiliar with the OpenMP flow. The IR that<br>
> I get from "clang -emit-llvm ..." contains calls to runtime functions<br>
> and I don't know how to link those into the IR. I am currently working<br>
> on the simple fact that my review request is showing failures with a<br>
> bunch of "libarcher" tests.<br>
><br>
> But now it seems I am getting failures locally with or without my<br>
> change. So, false alarm, maybe?<br>
<br>
Libarcher tests fail for all phab reviews for a while. That has nothing<br>
to do with your patch.<br></blockquote><div><br></div><div>It was said to have been fixed a couple of days ago, I'd try to rebase and retry!</div><div>Also check if you can reproduce locally.</div><div><br></div><div>Cheers,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
As far as I can tell there is no use of `convergent` on the CPU,<br>
or at least it would not mean much.<br>
<br>
~ Johannes<br>
<br>
<br>
> Sameer.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>