<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jun 26, 2015 at 2:01 PM Sanjay Patel <<a href="mailto:spatel@rotateright.com">spatel@rotateright.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Fri, Jun 26, 2015 at 2:17 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, Jun 26, 2015 at 12:51:38PM -0600, Sanjay Patel wrote:<br>
> Assuming the transform is correct, what is the recommended way to write<br>
> this in C/C++ to achieve the desired effect: we want both comparisons to be<br>
> evaluated (do *not* want short-circuiting)?<br>
<br>
</span>Why do you want that?<br></blockquote><div> </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>For performance. The statement that materializing the condition bits is as expensive as a branch is dependent on the arch, uarch, and data set. We're currently only using arch for the DAG transform. So for example, x86 globally changes all of these while PPC does not. SimplifyCFG doesn't even consider arch and does the inverse transform.<br></div></div></div></div></blockquote><div><br></div><div>I don't have any problem teaching codegen to use very specific information to weigh the costs of an additional branch. But that needs to be done in codegen, as it is rare on x86 at this point that a well predicted branch is more expensive than anything, and given the quality of branch predictors on x86, it is also relatively rare that branches are so unpredictable.</div><div><br></div><div>Again, we need to support both sides (lots of architectures outside of x86 with weaker branch prediction!) but it should be a detailed arch decision of how to lower this kind of code.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>The programmer may have more knowledge about the predictability of a specific branch and would like a way to specify that to the compiler.<br></div></div></div></div></blockquote><div><br></div><div>We could introduce an *unpredictabie* annotation to LLVM if there is sufficient demand for this. Specifically, this is different from a 50/50 probability, as it implies a lack of pattern which the processor can exploit to predict the behavior. This doesn't seem like a bad construct for LLVM to have, although it seems like an expensive one to add and so I would want to see a lot of really compelling evidence that we *have* to let programmers make this annotation.</div><div><br></div><div><br></div><div>However, I'm really strongly opposed to tying this in any way to the bitwise and operator. That is madness. What about masking bits signifies anything about predictability? What about all the cases where I'm not using and but I still have unpredictable branches that should be avoided if possible?</div><div><br></div><div>If you want to add support to *clang* for this, you'd be much better off proposing something like __builtin_expect which instead annotates a lack of predictability. I'm much more willing to tolerate code that looks like:</div><div><br></div><div>  if (UNPREDICTABLE(x < 3) && UNPREDICTABLE(y > 7)) { ... }</div><div><br></div><div>That is, if we actually must support this. I'm still extremely skeptical of the entire value proposition here.</div></div></div>