Hi Language Lawyers! In PR23827 ( https://llvm.org/bugs/show_bug.cgi?id=23827 ), a bitwise op on booleans is considered equivalent to a logical op: if ((x < 3) & (y > 10)) effectively becomes: if ((x < 3) && (y > 10)) where x and y are of type 'int'. The second statement (&&) requires short-circuit evaluation to bypass the y comparison when the x comparison is false (creates an extra branch vs. the original code).>From N4296 -4.5 Integral Promotions: "A prvalue of type bool can be converted to a prvalue of type int, with false becoming zero and true becoming one." 5.11 Bitwise AND operator: "The usual arithmetic conversions are performed; the result is the bitwise AND function of the operands." Is the type promotion optional ("can be")? Under what conditions would the promotion be performed? Assuming the transform is correct, what is the recommended way to write this in C/C++ to achieve the desired effect: we want both comparisons to be evaluated (do *not* want short-circuiting)? FWIW, the IR coming out of clang looks like what I expect: the i1 types are zexted and fed into an 'and i32'. It's the IR and backend optimizations that are surprising me. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150626/2fa57b85/attachment.html>
On Fri, Jun 26, 2015 at 12:51:38PM -0600, Sanjay Patel wrote:> Assuming the transform is correct, what is the recommended way to write > this in C/C++ to achieve the desired effect: we want both comparisons to be > evaluated (do *not* want short-circuiting)?Why do you want that? As long as the evaluation of x and y is side-effect free, the transform is valid and how the backend is lowering is doesn't matter. Keep in mind that materializing the 0/1 bits is often as expensive as doing a short-circuite jump. Joerg
On Fri, Jun 26, 2015 at 2:17 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:> On Fri, Jun 26, 2015 at 12:51:38PM -0600, Sanjay Patel wrote: > > Assuming the transform is correct, what is the recommended way to write > > this in C/C++ to achieve the desired effect: we want both comparisons to > be > > evaluated (do *not* want short-circuiting)? > > Why do you want that? >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. The programmer may have more knowledge about the predictability of a specific branch and would like a way to specify that to the compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150626/5369c031/attachment.html>
On Fri, Jun 26, 2015 at 11:51 AM, Sanjay Patel <spatel at rotateright.com> wrote:> Hi Language Lawyers! > > In PR23827 ( https://llvm.org/bugs/show_bug.cgi?id=23827 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D23827&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=17BngoQArftkINet3NRNu9WVFtBzGDM6quiH-_vyFTU&s=TVzKPGZzSHkGDgQLIbe15YwNCTM_cJ9c_5Zhevtot2Q&e=> > ), a bitwise op on booleans is considered equivalent to a logical op: > > if ((x < 3) & (y > 10)) > > effectively becomes: > > if ((x < 3) && (y > 10)) > > where x and y are of type 'int'. The second statement (&&) requires > short-circuit evaluation to bypass the y comparison when the x comparison > is false (creates an extra branch vs. the original code). > > From N4296 - > 4.5 Integral Promotions: > "A prvalue of type bool can be converted to a prvalue of type int, with > false becoming zero and true becoming one." > > 5.11 Bitwise AND operator: > "The usual arithmetic conversions are performed; the result is the bitwise > AND function of the operands." > > Is the type promotion optional ("can be")? Under what conditions would the > promotion be performed? >"can be" here just means "this is one of the available conversions".> > Assuming the transform is correct, what is the recommended way to write > this in C/C++ to achieve the desired effect: we want both comparisons to be > evaluated (do *not* want short-circuiting)? >This all falls under the as-if rule; there is nothing the user can do that will *require* the compiler to do either thing. -- Sean Silva> > FWIW, the IR coming out of clang looks like what I expect: the i1 types > are zexted and fed into an 'and i32'. It's the IR and backend optimizations > that are surprising me. > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150626/cf6c718a/attachment.html>