[llvm-bugs] [Bug 27434] New: LVI gives up too early on zext / lshr

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: regehr at cs.utah.edu
                CC: listmail at philipreames.com, llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160420/07ef89fd/attachment.html>