[llvm-bugs] [Bug 27506] New: GVN's propagateEquality propagates wrong equality

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27506

            Bug ID: 27506
           Summary: GVN's propagateEquality propagates wrong equality
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: kyoonss at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 16264
  --> https://llvm.org/bugs/attachment.cgi?id=16264&action=edit
llvm code that exposes error

GVN's `propagateEquality` propagates wrong equality related to icmp
instructions.

When it propagates such as "(icmp eq A B) == true", it also propagates "A ==
B". However, this may cause an incorrect behavior if either A or B is an
undefined value.

When the source code like below is given, GVN transforms the "b1" block as
shown. Suppose %x has a normal value and %u has the undef value. In the source,
"%aa" is always defined. However, in the target, "%aa" is replaced with "%u",
which is undef.

We attach an input llvm file of "opt -gvn" and a C example code that exposes
the same problem when compiled using "clang -O2". We tested this in both clang
3.7.1 and the trunk.


b0:
  %a = add i32 %x, 1
  %c = icmp eq i32 %a, %u
  br i1 %c, label %b1, label %b2

b1:
  %aa = add i32 %x, 1
  %d = call i32 @bar(i32 %aa)

->

b1:
  %d = call i32 @bar(i32 %u)

-- 
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/20160425/4f1f284f/attachment-0001.html>