[llvm-bugs] [Bug 46389] New: Inconsistent optimization of code using __builtin_ctz when changing the return type

[via llvm-bugs]

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

            Bug ID: 46389
           Summary: Inconsistent optimization of code using __builtin_ctz
                    when changing the return type
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: gabravier at gmail.com
                CC: llvm-bugs at lists.llvm.org

unsigned long f(uint64_t value)
{
    unsigned int result;

    if ((value & 0xFFFFFFFF) == 0)
    {
        result = __builtin_ctz(value >> 32) + 32;
    }
    else
    {
        if ((unsigned int)value != 0)
            result = __builtin_ctz((unsigned int)value);
    }

    return result;
}

With -O3, LLVM outputs this :

f(unsigned long): # @f(unsigned long)
  mov rax, rdi
  shr rax, 32
  tzcnt ecx, eax
  or ecx, 32
  tzcnt eax, edi
  cmovb eax, ecx
  ret

If the return type is changed from `unsigned long` to `unsigned int`, LLVM
outputs this :

f(unsigned long): # @f(unsigned long)
  test edi, edi
  je .LBB0_1
  tzcnt eax, edi
  ret
.LBB0_1:
  shr rdi, 32
  tzcnt eax, edi
  or eax, 32
  ret

This seems rather inconsistent considering that the two outputs are
functionally completely identical (at least, as far as I can see.

-- 
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/20200618/4f8311c6/attachment.html>