[LLVMbugs] [Bug 16671] New: Inefficient XOR calculation

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16671

            Bug ID: 16671
           Summary: Inefficient XOR calculation
           Product: libraries
           Version: 3.2
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: nruslan_devel at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The backend seems to be not smart enough to generate good code for the example
below. The line '(a >> 63) ^ a' will do NOT operation if the operand is
negative. Also suppose it already preceeds by a line which makes sure that the
operand is non-negative, i.e. '(a >> 63) ^ a' should be optimized to just 'a'.

long long func(long long a)
{
    if (a < 0) /* Condition, presumably somewhere before the code below */
        return 0;
    return (a >> 63 ) ^ a;
}

Clang produces the following code:

    testq   %rdi, %rdi
    js  .LBB0_1
    movq    %rdi, %rax
    sarq    $63, %rax
    xorq    %rdi, %rax
    ret
.LBB0_1:
    xorl    %eax, %eax
    ret

GCC produces optimized code:

    xorl    %eax, %eax
    testq   %rdi, %rdi
    cmovns  %rdi, %rax
    ret

Similar inefficiency if we reverse condition, i.e. now it should simply do NOT
operation:

long long func(long long a)
{
    if (a >= 0) /* Condition, presumably somewhere before the code below */
        return 0;
    return (a >> 63 ) ^ a;
}

Clang produces:

    testq   %rdi, %rdi
    js  .LBB0_2
    xorl    %eax, %eax
    ret
.LBB0_2:
    movq    %rdi, %rax
    sarq    $63, %rax
    xorq    %rdi, %rax
    ret

GCC produces:

    movq    %rdi, %rdx
    xorl    %eax, %eax
    testq   %rdi, %rdi
    notq    %rdx
    cmovs   %rdx, %rax
    ret

-- 
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/20130722/703421a4/attachment.html>