[LLVMbugs] [Bug 20945] New: InstCombine: constant comparison involving ashr is wrongly simplified.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=20945

            Bug ID: 20945
           Summary: InstCombine: constant comparison involving ashr is
                    wrongly simplified.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: andrea.dibiagio at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13042
  --> http://llvm.org/bugs/attachment.cgi?id=13042&action=edit
Possible fix.

Example:

define i32 @negative_constants(i32 %B) {
entry:
  %shr = ashr i32 -9, %B
  %cmp = icmp ne i32 %shr, -5
  br i1 %cmp, label %if.then, label %return

if.then:
  br label %return

return:
  %retval = phi i32 [ 0, %if.then ], [ 42, %entry ]
  ret i32 %retval
}

The instruction combiner wrongly thinks that statement 'ashr i32 -9, %B' can
never evaluate to -5. Therefore, it wrongly assumes that %cmp would always be
'true' and the branch to if.then would always be taken.

In this reproducible, if %B is equal to 1, then %cmp is 'false' (since %shr
would be equal to -5).
Therefore, it is not safe to fold %cmp to 'true'. What instead should be done
is converting the comparison between %shr and -5 into a comparison between %B
and 1. This would allow us to get rid of the arithmetic shift (and eventually
simplify the CFG folding the compare-and-branch into a single select of either
0 or 42).

This is a regression introduced by revision 213678.

I attached a patch that fixes this issue (I plan to send this patch on the
mailing list for review).

-- 
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/20140915/161501cd/attachment.html>