[llvm-bugs] [Bug 28476] New: [InstCombine] functionally-equivalent comparison code produces different IR

[via llvm-bugs]

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

            Bug ID: 28476
           Summary: [InstCombine] functionally-equivalent comparison code
                    produces different IR
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: spatel+llvm at rotateright.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

int good(int x, int y) {
  return (x == 0 || y == 0) ? 1 : 0;
}
int bad(int x, int y) {
  return (x != 0 && y != 0) ? 0 : 1;
}

These are equivalent (DeMorgan's Law), but they generate different IR (and
ultimately different asm):

$ ./clang -O1 xy.c -S -o - -emit-llvm

define i32 @good(i32 %x, i32 %y) local_unnamed_addr #0 {
entry:
  %cmp = icmp eq i32 %x, 0
  %cmp1 = icmp eq i32 %y, 0
  %0 = or i1 %cmp, %cmp1
  %cond = zext i1 %0 to i32
  ret i32 %cond
}


define i32 @bad(i32 %x, i32 %y) local_unnamed_addr #0 {
entry:
  %cmp = icmp ne i32 %x, 0
  %cmp1 = icmp ne i32 %y, 0
  %0 = and i1 %cmp, %cmp1
  %1 = zext i1 %0 to i32
  %cond = xor i32 %1, 1
  ret i32 %cond
}

--------------------------------------------------------------------------

I think this can be fixed by removing a canonicalization in
InstCombiner::visitZExt() that causes us to miss 'not' logic:

  // zext (xor i1 X, true) to i32  --> xor (zext i1 X to i32), 1

This issue also came up in:
http://reviews.llvm.org/D21899

-- 
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/20160708/2905ec21/attachment.html>