1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 20:23:11 +01:00
llvm-mirror/test/Transforms/NewGVN/pr32897.ll
Daniel Berlin 16f68ec6d3 NewGVN: Fix PR/33187. This is a bug caused by two things:
1. When there is no perfect iteration order, we can't let phi nodes
put themselves in terms of things that come later in the iteration
order, or we will endlessly cycle (the normal RPO algorithm clears the
hashtable to avoid this issue).
2. We are sometimes erasing the wrong expression (causing pessimism)
because our equality says loads and stores are the same.
We introduce an exact equality function and use it when erasing to
make sure we erase only identical expressions, not equivalent ones.

llvm-svn: 304807
2017-06-06 17:15:28 +00:00

26 lines
692 B
LLVM

; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
; RUN: opt -S -newgvn %s | FileCheck %s
define void @tinkywinky(i64* %b) {
; CHECK-LABEL: @tinkywinky(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[BODY:%.*]]
; CHECK: body:
; CHECK-NEXT: store i64 undef, i64* [[B:%.*]]
; CHECK-NEXT: br i1 undef, label [[BODY]], label [[END:%.*]]
; CHECK: end:
; CHECK-NEXT: br label [[BODY]]
;
entry:
br label %body
body:
%d.1 = phi i64* [ undef, %entry ], [ %d.1, %body ], [ %b, %end ]
store i64 undef, i64* %d.1
%b2 = load i64, i64* %b
%or = or i64 %b2, 0
store i64 %or, i64* %b
br i1 undef, label %body, label %end
end:
br label %body
}