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

            Bug ID: 38461
           Summary: Incorrect InstCombine urem removal with undef values
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedb...@nondot.org
          Reporter: nunoplo...@sapo.pt
                CC: llvm-bugs@lists.llvm.org, reg...@cs.utah.edu,
                    spatel+l...@rotateright.com

The following functions gets miscompiled:

define i2 @foo(i2, i1, i4, i2, i1, i4, i2, i1, i4, i2, i1, i4) {
  %13 = urem i2 %0, -1
  ret i2 %13
}

$ opt -S -instcombine urem.ll
define i2 @foo(i2, i1, i4, i2, i1, i4, i2, i1, i4, i2, i1, i4) {
  %13 = icmp eq i2 %0, -1
  %14 = zext i1 %13 to i2
  %15 = add i2 %14, %0
  ret i2 %15
}


Alive2 complains about this:
----------------------------------------
  %13 = urem i2 %0, -1
  ret i2 %13
=>
  %13 = icmp eq i2 %0, -1
  %14 = zext i1 %13 to i2
  %15 = add i2 %14, %0
  ret i2 %15

ERROR: Value mismatch

Example:
i2 %0 = undef
src:
i2 %13 = 0x0 (0)
tgt:
i1 %13 = 0x0 (0)
i2 %14 = 0x0 (0)
i2 %15 = 0x3 (3, -1)
Source value: 0x0 (0)
Target value: 0x3 (3, -1)


The transformation is incorrect because it increases the number of uses of %0.
Since when undef is read it may return a different value, it's not safe to
increase the number of reads like this, as is exemplified in the counterexample
above.

[P.S.: The online version of Alive unfortunately incorrectly says that this
transformation is correct. It doesn't model multiple undef uses soundly. Alive2
does, and will be available soonish]

-- 
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

Reply via email to