[llvm-bugs] [Bug 36437] New: [NewGVN] Seemingly incorrect transformation.

[via llvm-bugs]

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

            Bug ID: 36437
           Summary: [NewGVN] Seemingly incorrect transformation.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: paulsson at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 19900
  --> https://bugs.llvm.org/attachment.cgi?id=19900&action=edit
reduced test case

I discovered a runtime error with csmith, which was tracked down to
-enable-newgvn. I have reduced the test case and it seems indeed that there is
something suspicious in the transformation of NewGVN:

*** IR Dump After MergedLoadStoreMotion ***
; Function Attrs: nounwind
define dso_local signext i32 @main() local_unnamed_addr #1 {
entry:
  store i64 0, i64* @g_27, align 8, !tbaa !8
  br label %for.body

for.body:                                         ; preds = %entry, %land.end
  %storemerge5 = phi i64 [ 0, %entry ], [ %inc3, %land.end ]
  %0 = load i32, i32* @g_49, align 4, !tbaa !6
  %tobool = icmp ne i32 %0, 0
  %tobool1 = icmp ne i64 %storemerge5, 0
  %or.cond = and i1 %tobool1, %tobool
  br i1 %or.cond, label %land.rhs, label %land.end

* %tobool compares %0, which is a load from @g_49, which is stored to in loop
* %storemerge5 starts from 0 and is incremented by 1, so %tobool1 is false
first iteration, then true.
* %or.cond is the and both both comparisons. First iteration must be false, the
rest depends on %tobool.

-> transformed into: ( rest of loop unmodified) ->

*** IR Dump After Global Value Numbering ***
; Function Attrs: nounwind
define dso_local signext i32 @main() local_unnamed_addr #1 {
entry:
  store i64 0, i64* @g_27, align 8, !tbaa !8
  br label %for.body

for.body:                                         ; preds = %entry, %land.end
  %phiofops6 = phi i1 [ false, %entry ], [ true, %land.end ]
  %phiofops = phi i1 [ false, %entry ], [ %tobool, %land.end ]
  %storemerge5 = phi i64 [ 0, %entry ], [ %inc3, %land.end ]
  %0 = load i32, i32* @g_49, align 4, !tbaa !6
  %tobool = icmp ne i32 %0, 0
  br i1 %phiofops, label %land.rhs, label %land.end

* First iteration: %phiofops is false, which is correct.
* Next iteration: %phiofops depends only on %tobol, which is correct, but this
seems to be %tobol of the *previous* iteration. This seems wrong, since @g_46
is stored to in the loop.
* %phiofops6 has no users!

---
/home/ijonpan/llvm/build/llvm-dev/bin/clang -O3 -march=z13  -o a.out -w
./creduced.i
./a.out
checksum = 0

/home/ijonpan/llvm/build/llvm-dev/bin/clang -O3 -march=z13  -o a.out -w
./creduced.i  -mllvm -enable-newgvn
./a.out
checksum = 10000

-- 
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/20180219/a8cee26b/attachment.html>