[LLVMbugs] [Bug 22727] New: [InstcombineCompares] generates incorrect code for double comparision

[bugzilla-daemon at llvm.org]

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

            Bug ID: 22727
           Summary: [InstcombineCompares] generates incorrect code for
                    double comparision
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: shivarama.rao at amd.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13960
  --> http://llvm.org/bugs/attachment.cgi?id=13960&action=edit
input file to reproduce the problem.

for the attached testcase with following IR:

  %i = ptrtoint i64*  %add.ptr to i64
  %conv = uitofp i64 %i to double
  %cmp = fcmp ogt double %conv, 0.000000e+00
  br i1 %cmp, label %if.then, label %if.else

opt -O2 generates following output


  %i = ptrtoint i64* %add.ptr to i64
  %cmp = icmp eq i64 %i, 0
  br i1 %cmp, label %if.else, label %if.then

In the input test we had fcmp ogt, which  got transformed into icmp eq which
doesnt seem to be correct. In the test input we are checking add.ptr > 0.0
whereas in the transformed code it is checked if %add.ptr == 0

The issue presents in trunk and is result of following checkin

commit d883ca0ca713c329deed614fa389230c7266d0e4
Author: Matt Arsenault <Matthew.Arsenault at amd.com>
Date:   Tue Jan 6 15:50:59 2015 +0000

    Convert fcmp with 0.0 from casted integers to icmp

    This is already handled in general when it is known the
    conversion can't lose bits with smaller integer types
    casted into wider floating point types.

-- 
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/20150227/16efd368/attachment.html>