maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

[NewGVN] Create a StoreExpression instead of a VariableExpression. 

In the case where we have an operand defined by a lod of the
same memory location. Historically this was a VariableExpression
because we wanted to make sure they ended up in the same class,
but if we create the right expression, they end up in the same
class anyway.

Fixes PR32897. Thanks to Dan for the detailed discussion and the
fix suggestion.

llvm-svn: 303475
This commit is contained in:
Davide Italiano 2017-05-20 00:46:54 +00:00
parent 421b63dd70
commit 9a0f542db6
2 changed files with 27 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
llvm/lib/Transforms/Scalar/NewGVN.cpp
View File

@ -1251,7 +1251,7 @@ const Expression *NewGVN::performSymbolicStoreEvaluation(Instruction *I) const {
lookupOperandLeader(SI->getPointerOperand())) &&
(lookupMemoryLeader(getMemoryAccess(LI)->getDefiningAccess()) ==
StoreRHS))
return createVariableExpression(LI);
return createStoreExpression(SI, StoreRHS);
}
}

26
llvm/test/Transforms/NewGVN/pr32897.ll Normal file
View File

@ -0,0 +1,26 @@
; 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: [[B2:%.*]] = load i64, 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
}