<div dir="ltr"><div><div><div>Ok, I understand better why the 'bitwise and' hack looks insane to you guys. :)<br>It would take a change in the C language spec to happen. Since that's practically impossible, it actually makes this mission a little clearer, if not easier.<br><br>There's widespread misunderstanding: <br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_questions_4014535_differences-2Din-2Dboolean-2Doperators-2Dvs-2Dand-2Dvs&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=yW62H3pdXHpTw9t-wvP5j2gIZ48VCbRmBIuxhkWIvo8&s=XGrfFqjbkTSG_XHJGf1-qj_LuxsQ9hBpIVRsFtBfbAI&e=">http://stackoverflow.com/questions/4014535/differences-in-boolean-operators-vs-and-vs</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_questions_1279217_difference-2Dbetween-2Dand-2Dor-2Dand-2Dfor-2Dcomparison&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=yW62H3pdXHpTw9t-wvP5j2gIZ48VCbRmBIuxhkWIvo8&s=mr1mFv6HYhPH4e3AdAbQb3J3fUUTnYPmyLZvP2r9FTg&e=">http://stackoverflow.com/questions/1279217/difference-between-and-or-and-for-comparison</a><br><br></div>I've personally used the & vs. && hack for optimization purposes on many occasions over the years, so I wonder if C optimizers have only recently (last 5 years or so?) gotten smart enough to transform those bitwise expressions back into logical.<br><br></div>In any case, I'll come up with some perf data to better illustrate the motivation.<br><br></div>Thanks!<br><div><br><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 27, 2015 at 10:16 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> From: "Chandler Carruth" <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
> To: "Sanjay Patel" <<a href="mailto:spatel@rotateright.com">spatel@rotateright.com</a>>, "Clang" <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>>, <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>,<br>
> <a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a><br>
> Sent: Friday, June 26, 2015 8:55:22 PM<br>
> Subject: Re: [LLVMdev] [cfe-dev] bitwise ops on booleans<br>
><br>
><br>
> On Fri, Jun 26, 2015 at 2:01 PM Sanjay Patel < <a href="mailto:spatel@rotateright.com">spatel@rotateright.com</a><br>
> > wrote:<br>
><br>
> On Fri, Jun 26, 2015 at 2:17 PM, Joerg Sonnenberger <<br>
> <a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a> > wrote:<br>
><br>
> 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<br>
> > write<br>
> > this in C/C++ to achieve the desired effect: we want both<br>
> > comparisons to be<br>
> > evaluated (do *not* want short-circuiting)?<br>
><br>
> Why do you want that?<br>
><br>
> For performance. The statement that materializing the condition bits<br>
> is as expensive as a branch is dependent on the arch, uarch, and<br>
> data set. We're currently only using arch for the DAG transform. So<br>
> for example, x86 globally changes all of these while PPC does not.<br>
> SimplifyCFG doesn't even consider arch and does the inverse<br>
> transform.<br>
><br>
> I don't have any problem teaching codegen to use very specific<br>
> information to weigh the costs of an additional branch. But that<br>
> needs to be done in codegen, as it is rare on x86 at this point that<br>
> a well predicted branch is more expensive than anything, and given<br>
> the quality of branch predictors on x86, it is also relatively rare<br>
> that branches are so unpredictable.<br>
><br>
> Again, we need to support both sides (lots of architectures outside<br>
> of x86 with weaker branch prediction!) but it should be a detailed<br>
> arch decision of how to lower this kind of code.<br>
><br>
><br>
> The programmer may have more knowledge about the predictability of a<br>
> specific branch and would like a way to specify that to the<br>
> compiler.<br>
><br>
> We could introduce an *unpredictabie* annotation to LLVM if there is<br>
> sufficient demand for this. Specifically, this is different from a<br>
> 50/50 probability, as it implies a lack of pattern which the<br>
> processor can exploit to predict the behavior. This doesn't seem<br>
> like a bad construct for LLVM to have, although it seems like an<br>
> expensive one to add and so I would want to see a lot of really<br>
> compelling evidence that we *have* to let programmers make this<br>
> annotation.<br>
><br>
> However, I'm really strongly opposed to tying this in any way to the<br>
> bitwise and operator. That is madness. What about masking bits<br>
> signifies anything about predictability? What about all the cases<br>
> where I'm not using and but I still have unpredictable branches that<br>
> should be avoided if possible?<br>
<br>
</div></div>I am also strongly opposed to this. Amusingly enough, I was taking part in a meeting over the last few days where, among other things, experienced developers from several labs were providing feedback on compiler development priorities for future systems. Their top general request was that we try harder to make sure that different ways of writing the same thing were optimized in equivalent ways. This seems like a nice example of the kind of thing to which they were referring. Implicit hints like this are a) not portable b) often not documented c) not stable across compiler upgrades and d) not obvious to readers of the code. We should try to fix these kinds of things when we find them, and not introduce them on purpose.<br>
<span class=""><br>
><br>
> If you want to add support to *clang* for this, you'd be much better<br>
> off proposing something like __builtin_expect which instead<br>
> annotates a lack of predictability. I'm much more willing to<br>
> tolerate code that looks like:<br>
<br>
</span>+1<br>
<br>
 -Hal<br>
<span class="im HOEnZb"><br>
><br>
><br>
> if (UNPREDICTABLE(x < 3) && UNPREDICTABLE(y > 7)) { ... }<br>
><br>
> That is, if we actually must support this. I'm still extremely<br>
> skeptical of the entire value proposition here.<br>
</span><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span></blockquote></div><br></div>