[llvm-bugs] [Bug 36622] New: clang does not properly optimize xor expressions

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36622

            Bug ID: 36622
           Summary: clang does not properly optimize xor expressions
           Product: clang
           Version: 5.0
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: avg at FreeBSD.org
                CC: llvm-bugs at lists.llvm.org

It appears that in some code sequences Clang fails to recognize that
x xor C xor C == x
where C is a compile-time constant.

For instance:
-----------------------------------------
uint32_t
combine(uint16_t x, uint16_t y)
{
        uint32_t r = 0x5a5a7777;

        r ^= (r ^ x) & 0xffff;
        r ^= ((r >> 16) ^ y) << 16;

        return (r);
}
-----------------------------------------

In this code the initial value of r is not important and the code should be
equivalent to:
-----------------------------------------
uint32_t
combine(uint16_t x, uint16_t y)
{
        return (x | ((uint32_t)y << 16));
}
-----------------------------------------


But even with -O3 Clang produces the following assembler code:
-----------------------------------------
        orl     $1515847680, %edi       # imm = 0x5A5A0000
        xorl    $23130, %esi            # imm = 0x5A5A
        shll    $16, %esi
        xorl    %edi, %esi
        movl    %esi, %eax
-----------------------------------------

It's easy to see that 0x5A5A will always cancel out through double application
via xor, but Clang does not recognize that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180306/99ec9627/attachment-0001.html>