https://llvm.org/bugs/show_bug.cgi?id=27434
Bug ID: 27434
Summary: LVI gives up too early on zext / lshr
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: reg...@cs.utah.edu
CC: listm...@philipreames.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
When a value is lshred or zexted, we can learn something about its value even
if we previously knew nothing. For example, LVI learns nothing from the zext
below, whereas it obviously should conclude that the value is in [0,2). The
problem is not in ConstantRange, which is perfectly willing to learn something
new from a zext, the problem is in LVI. It looks like probably we're bailing
too early in solveBlockValueConstantRange().
There are probably other instructions affected by this, but the problem is
extremely noticeable for lshr and zext.
define i32 @foo8(i1 %x) {
entry:
%ret = zext i1 %x to i32
ret i32 %ret
}
; Function Attrs: noreturn nounwind
declare void @llvm.trap() #0
attributes #0 = { noreturn nounwind }
--
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
