<div dir="ltr"><div dir="ltr">To confirm with Dave's minimal example, the metadata does survive the IR optimizer in that case:</div><div dir="ltr">$ clang -O2 unpred.c -S -o - -emit-llvm | grep unpredictable<br>  br i1 %cmp, label %cond.true, label %cond.end, !unpredictable !3<br></div><div dir="ltr"><br></div><div>So yes, it's the backend (x86 cmov conversion pass) that doesn't have access to the metadata and transforms to branch.<br></div><div><br></div><div>This was discussed here with some compelling perf claims:<br></div><div dir="ltr"><a href="https://bugs.llvm.org/show_bug.cgi?id=40027" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=40027</a></div><div><br></div><div>And similarly/originally filed including different perf harm:</div><div><a href="https://bugs.llvm.org/show_bug.cgi?id=37144" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=37144</a></div><div><br></div><div>And there are side-channel/crypto/constant-time comments here:</div><div><a href="https://bugs.llvm.org/show_bug.cgi?id=42901" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=42901</a></div><div><br></div><div>I'm not sure if this changes/adds anything for the above bugs and the examples in this thread, but we recently made an x86 change to favor cmov for perf in:</div><div><a href="https://reviews.llvm.org/D67087">https://reviews.llvm.org/D67087</a></div><div>based on perf numbers in:</div><div><a href="https://bugs.llvm.org/show_bug.cgi?id=43197">https://bugs.llvm.org/show_bug.cgi?id=43197</a></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 14, 2019 at 2:18 AM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 14, 2019 at 12:12 AM David Zarzycki <<a href="mailto:dave@znu.io" target="_blank">dave@znu.io</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"><div dir="auto">Hi Chandler,<div><br></div><div>I feel like this conversation has come full circle. So to ask again: how does one force CMOV to be emitted? You suggested “__builtin_unpredictable()” but that gets lost in various optimization passes. Given other architectures have CMOV like instructions, and given the usefulness of the instruction for performance tuning, it seems like a direct intrinsic would be best. What am I missing?</div></div></blockquote><div><br></div><div>LLVM operates at a higher level of abstraction IMO, so I don't really feel like there is something missing here. LLVM is just choosing a lowering that is expected to be superior even in the face of an unpredictable branch.</div><div><br></div><div>If there are real world benchmarks that show it this lowering strategy is a problem, file bugs with those benchmarks? We can always change the heuristics based on new information.</div><div><br></div><div>I think if you want to force a particular instruction to be used, there is already a pretty reasonable approach: inline assembly.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br></div><div>Dave<br><div><div dir="ltr"><br><blockquote type="cite">On Sep 14, 2019, at 8:35 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">The x86 backend is extremely aggressive in turning cmov with memory operands into branches because that is often faster even for poorly predicted branches due to the forced stall in the cmov.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2019 at 11:19 PM David Zarzycki <<a href="mailto:dave@znu.io" target="_blank">dave@znu.io</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">I’m struggling to find cases where __builtin_unpredictable() works at all. Even if we ignore cmp/br into switch conversion, it still doesn’t work:<br>
<br>
int test_cmov(int left, int right, int *alt) {<br>
        return __builtin_unpredictable(left < right) ? *alt : 999;<br>
}<br>
<br>
Should generate:<br>
<br>
test_cmov:<br>
        movl    $999, %eax<br>
        cmpl    %esi, %edi<br>
        cmovll  (%rdx), %eax<br>
        retq<br>
<br>
But currently generates:<br>
<br>
test_cmov:<br>
        movl    $999, %eax<br>
        cmpl    %esi, %edi<br>
        jge     .LBB0_2<br>
        movl    (%rdx), %eax<br>
.LBB0_2:<br>
        retq<br>
<br>
<br>
<br>
> On Sep 14, 2019, at 12:18 AM, Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>> wrote:<br>
> <br>
> I'm not sure if this is the entire problem, but SimplifyCFG loses the 'unpredictable' metadata when it converts a set of cmp/br into a switch:<br>
> <a href="https://godbolt.org/z/neLzN3" rel="noreferrer" target="_blank">https://godbolt.org/z/neLzN3</a><br>
> <br>
> Filed here:<br>
> <a href="https://bugs.llvm.org/show_bug.cgi?id=43313" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=43313</a><br>
> <br>
> On Fri, Sep 13, 2019 at 4:02 AM David Zarzycki via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> <br>
>> On Sep 13, 2019, at 10:45 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<br>
>> <br>
>> On Fri, Sep 13, 2019 at 1:33 AM David Zarzycki via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> Hi Chandler,<br>
>> <br>
>> The data-invariant feature sounds great but what about the general case? When performance tuning code, people sometimes need the ability to reliably generate CMOV, and right now the best advice is either “use inline assembly” or “keep refactoring until CMOV is emited” (and hope that future compilers continue to generate CMOV).<br>
>> <br>
>> Given that a patch already exists to reliably generate CMOV, are there any good arguments against adding the feature?<br>
>> <br>
>> For *performance* tuning, the builtin that Hal mentioned is IMO the correct design.<br>
>> <br>
>> Is there some reason why it doesn't work?<br>
> <br>
> I wasn’t aware of __builtin_unpredictable() until now and I haven’t debugged why it doesn’t work, but here are a couple examples, one using the ternary operator and one using a switch statement:<br>
> <br>
> <a href="https://godbolt.org/z/S46I_q" rel="noreferrer" target="_blank">https://godbolt.org/z/S46I_q</a><br>
> <br>
> Dave<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>
<br>
</blockquote></div>
</div></blockquote></div></div></div></blockquote></div></div>
</blockquote></div></div>