[llvm-bugs] [Bug 28442] New: We should generate the xor idiom instead of movzbl for zext even if not directly fed by setcc.

[via llvm-bugs]

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

            Bug ID: 28442
           Summary: We should generate the xor idiom instead of movzbl for
                    zext even if not directly fed by setcc.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: mkuper at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider:
int foo(int a, int b, int c) {
  return (a > 0 && b > 0 && c > 0);
}

Right now, we generate:
    testl    %edi, %edi
    setg    %al
    testl    %esi, %esi
    setg    %cl
    andb    %al, %cl
    testl    %edx, %edx
    setg    %al
    andb    %cl, %al
    movzbl    %al, %eax
    retq

This does not get caught by r274692, because the setcc doesn't feed directly
into the zext. This is true starting from the IR level:

  %cmp = icmp sgt i32 %a, 0
  %cmp1 = icmp sgt i32 %b, 0
  %or.cond = and i1 %cmp, %cmp1
  %cmp2 = icmp sgt i32 %c, 0
  %cmp2. = and i1 %or.cond, %cmp2
  %land.ext = zext i1 %cmp2. to i32
  ret i32 %land.ext

The performance impact is the same as in the usual "setcc + zext" cases:

int main() {
  unsigned x = 0;
  unsigned y = 0;
  for (unsigned i = 0; i < 2000; ++i) {
    for (unsigned j = 0; j < 2000; ++j) {
      for (unsigned k = 0; k < 2000; ++k) {
        y += ((i >= 10) && (j >= 20) && (k >= 30));
      }
    }
  }
  return y;
}

When compiled with clang -O2 -fno-vectorize -fno-unroll-loops runs for 7.8s on
my machine. Using the xor idiom, it runs for 4.9s.

-- 
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/20160707/6744f8a1/attachment.html>