<div dir="ltr"><div dir="ltr">On Wed, Jun 2, 2021 at 4:07 AM John McCall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><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:sans-serif"><div style="white-space:normal">
<p dir="auto">A function that participates and isn’t marked convergent should probably default to being non-convergent, because that’s the conservative assumption (I believe). But if a function doesn’t participate in the analysis at all, well, it just doesn’t apply.</p></div></div></div></blockquote><div>Based on the name, I agree it does feel like "non-convergent" would be the conservative assumption. But IIUC, that's unfortunately not the case, and is why this proposal to change the default is being made.</div><div><br></div><div>"Convergent" actually means something like "This function <i>might </i>depend on the alignment of control-flow across multiple threads in order to exchange data with the implicit set of neighboring threads which are executing the same instruction at the same time". Non-convergent means the opposite: that the code -- including any transitive functions it calls -- is known to NOT have any such cross-thread interaction.</div><div><br></div><div>When you know the code doesn't have these cross-thread interactions, you have additional optimizations available that are unsafe when there is such cross-thread interaction.</div><div><br></div><div><div dir="ltr" class="gmail_attr">On Tue, Jun 1, 2021 at 7:59 AM Sameer Sahasrabuddhe 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:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2. D69498 will be updated so that the convergent property is made<br>   default, but the new requirements on CPU frontends will be retracted.</blockquote><div><br></div><div>If I understand correctly, this means the Clang frontend will no longer need to add any convergent NOR noconvergent attributes. Instead, LLVM analysis passes can infer the new noconvergent attribute as appropriate. And on non-GPU platforms, the analysis can be skipped, and the optimization passes can simply ignore convergence attributes, because the hardware has no operations which can observe convergence. (So, it doesn't matter whether a function is marked noconvergent or not.)</div><div><br></div><div>Which is to say: this proposal should make things <i>easier</i> for "naive" frontends, not harder. By default, a reasonable thing should happen when the frontend does nothing -- both on GPU platforms and non-GPU platforms. Especially if all of the code is in a single module (e.g., via LTO), there will be few calls to unknown destinations, so noconvergent can be inferred basically everywhere that is not <i>in fact</i> dependent on convergence.</div></div></div>