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: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
