[llvm-bugs] [Bug 32524] New: x86: inefficient code for x == 0 || x == 1

[via llvm-bugs]

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

            Bug ID: 32524
           Summary: x86: inefficient code for x == 0 || x == 1
           Product: new-bugs
           Version: 4.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: llvm-bugs at lists.llvm.org
            Blocks: 26299

For the example code:

bool f(int x) {
  return x == 0 || x == 1;
}

Clang generates (10 bytes):

 or     edi,0x1
 cmp    edi,0x1
 sete   al
 ret 

GCC and MSVC generate (7 bytes):

 cmp    edi,0x1
 setbe  al
 ret


At -Os, Clang's code gets even worse, not clear why (14 bytes):

 or     edi,0x1
 mov    eax,0x1
 cmp    edi,eax
 sete   al
 ret



I suppose LLVM notices that the conditions only differ in the least significant
bit, as in the example below where the strategy makes sense:


bool g(int x) {
  return x == 4 || x == 5;
}


Clang:

 or     edi,0x1
 cmp    edi,0x5
 sete   al
 ret

GCC:

 sub    edi,0x4
 cmp    edi,0x1
 setbe  al
 ret





A related case is this one:

bool h(int x) {
  return x == -1 || x == 0;
}

Clang (14 bytes):

h(int):
 cmp    edi,0xffffffff
 sete   cl
 test   edi,edi
 sete   al
 or     al,cl
 ret

GCC (10 bytes):

h(int):
 add    edi,0x1
 cmp    edi,0x1
 setbe  al
 ret


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=26299
[Bug 26299] [meta][X86] Size optimization opportunities (in particular for
32-bit Chromium on Windows)
-- 
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/20170404/384906d8/attachment.html>