https://llvm.org/bugs/show_bug.cgi?id=27869
Bug ID: 27869
Summary: Optimizer doesn't simplify obvious contradiction
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: m...@manueljacob.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following C code contains an "obvious" contradiction. An integer can't
both be 0 and negative, so this should be simplifies to false:
_Bool test(int i) {
return (i == 0) & (i < 0);
}
The LLVM IR with SROA run on it:
define zeroext i1 @test(i32 %i) #0 {
entry:
%cmp = icmp eq i32 %i, 0
%conv = zext i1 %cmp to i32
%cmp1 = icmp slt i32 %i, 0
%conv2 = zext i1 %cmp1 to i32
%and = and i32 %conv, %conv2
%tobool = icmp ne i32 %and, 0
ret i1 %tobool
}
However running all optimizations on it will result in the following code:
define zeroext i1 @test(i32 %i) #0 {
entry:
%cmp = icmp eq i32 %i, 0
%conv = zext i1 %cmp to i32
%i.lobit = lshr i32 %i, 31
%and = and i32 %conv, %i.lobit
%tobool = icmp ne i32 %and, 0
ret i1 %tobool
}
The problem is that InstCombine transforms the (zext (< i 0)) pattern into
clever bit shifting: (lshr i 31). At first this saves one operation, but then
the obvious contradiction is obfuscated.
I see two options how to solve this:
1) Deferring the (zext (< i 0)) -> (lshr i 31) transformation, allowing
InstCombine to simplify the contradiction.
2) Making subsequent transformations more clever, so they can "look through"
the lshr instruction, seeing that it's actually a "less than" predicate.
--
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
