[llvm-bugs] [Bug 31924] New: Missed optimization for comparison of uin64_t values on 32-bit platform

[via llvm-bugs]

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

            Bug ID: 31924
           Summary: Missed optimization for comparison of uin64_t values
                    on 32-bit platform
           Product: clang
           Version: 3.9
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mizvekov at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider the following simple example:

bool comp1(__UINT64_TYPE__ a) {
    return a >= 0x1234567800000000llu;
}

bool comp2(__UINT64_TYPE__ a) {
    __UINT32_TYPE__ b = a >> 32;
    return b >= 0x12345678u;
}

When compiled with "-Os -march=i686 -m32 -fomit-frame-pointer" the following
code is generated:

comp1(unsigned long long):                              # @comp1(unsigned long
long)
        mov     eax, dword ptr [esp + 8]
        shr     eax, 3
        cmp     eax, 38177486
        seta    al
        ret

comp2(unsigned long long):                              # @comp2(unsigned long
long)
        cmp     dword ptr [esp + 8], 305419895
        seta    al
        ret

Notice the redundant right shifting of the lhs value in the comp1 version.

For comparison, gcc generates optimal code for both versions:

comp1(unsigned long long):
        cmp     DWORD PTR [esp+8], 305419895
        seta    al
        ret
comp2(unsigned long long):
        cmp     DWORD PTR [esp+8], 305419895
        seta    al
        ret

This is the IR emited by clang:

; Function Attrs: norecurse nounwind optsize readnone
define zeroext i1 @_Z5comp1y(i64) local_unnamed_addr #0 {
  %2 = icmp ugt i64 %0, 1311768464867721215
  ret i1 %2
}

; Function Attrs: norecurse nounwind optsize readnone
define zeroext i1 @_Z5comp2y(i64) local_unnamed_addr #0 {
  %2 = lshr i64 %0, 32
  %3 = trunc i64 %2 to i32
  %4 = icmp ugt i32 %3, 305419895
  ret i1 %4
}

So basically the basic structure of the problem is already present when emitted
by the front end, and later optimization passes can't fix it.

-- 
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/20170209/320f8854/attachment.html>