[cfe-dev] bitwise ops on booleans

[Sean Silva]

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/cfe-dev/attachments/20150626/cf6c718a/attachment.html>