summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ScalarEvolutionExpander.cpp
diff options
context:
space:
mode:
authorWei Mi <wmi@google.com>2016-02-04 01:27:38 +0000
committerWei Mi <wmi@google.com>2016-02-04 01:27:38 +0000
commita49559befb66d585fdb64c2bae63eca6c98a3e8f (patch)
tree9d6723751c41a43f70e50b8187af61a3ac3e363b /llvm/lib/Analysis/ScalarEvolutionExpander.cpp
parent69cb000974ef63d9c016f2e230a254ea37622286 (diff)
downloadbcm5719-llvm-a49559befb66d585fdb64c2bae63eca6c98a3e8f.tar.gz
bcm5719-llvm-a49559befb66d585fdb64c2bae63eca6c98a3e8f.zip
[SCEV] Try to reuse existing value during SCEV expansion
Current SCEV expansion will expand SCEV as a sequence of operations and doesn't utilize the value already existed. This will introduce redundent computation which may not be cleaned up throughly by following optimizations. This patch introduces an ExprValueMap which is a map from SCEV to the set of equal values with the same SCEV. When a SCEV is expanded, the set of values is checked and reused whenever possible before generating a sequence of operations. The original commit triggered regressions in Polly tests. The regressions exposed two problems which have been fixed in current version. 1. Polly will generate a new function based on the old one. To generate an instruction for the new function, it builds SCEV for the old instruction, applies some tranformation on the SCEV generated, then expands the transformed SCEV and insert the expanded value into new function. Because SCEV expansion may reuse value cached in ExprValueMap, the value in old function may be inserted into new function, which is wrong. In SCEVExpander::expand, there is a logic to check the cached value to be used should dominate the insertion point. However, for the above case, the check always passes. That is because the insertion point is in a new function, which is unreachable from the old function. However for unreachable node, DominatorTreeBase::dominates thinks it will be dominated by any other node. The fix is to simply add a check that the cached value to be used in expansion should be in the same function as the insertion point instruction. 2. When the SCEV is of scConstant type, expanding it directly is cheaper than reusing a normal value cached. Although in the cached value set in ExprValueMap, there is a Constant type value, but it is not easy to find it out -- the cached Value set is not sorted according to the potential cost. Existing reuse logic in SCEVExpander::expand simply chooses the first legal element from the cached value set. The fix is that when the SCEV is of scConstant type, don't try the reuse logic. simply expand it. Differential Revision: http://reviews.llvm.org/D12090 llvm-svn: 259736
Diffstat (limited to 'llvm/lib/Analysis/ScalarEvolutionExpander.cpp')
-rw-r--r--llvm/lib/Analysis/ScalarEvolutionExpander.cpp28
1 files changed, 27 insertions, 1 deletions
diff --git a/llvm/lib/Analysis/ScalarEvolutionExpander.cpp b/llvm/lib/Analysis/ScalarEvolutionExpander.cpp
index 1356fdced41..f95e191e5ee 100644
--- a/llvm/lib/Analysis/ScalarEvolutionExpander.cpp
+++ b/llvm/lib/Analysis/ScalarEvolutionExpander.cpp
@@ -1598,6 +1598,12 @@ Value *SCEVExpander::expandCodeFor(const SCEV *SH, Type *Ty) {
return V;
}
+// The expansion of SCEV will either reuse a previous Value in ExprValueMap,
+// or expand the SCEV literally. Specifically, if the expansion is in LSRMode,
+// and the SCEV contains any sub scAddRecExpr type SCEV, it will be expanded
+// literally, to prevent LSR's transformed SCEV from being reverted. Otherwise,
+// the expansion will try to reuse Value from ExprValueMap, and only when it
+// fails, expand the SCEV literally.
Value *SCEVExpander::expand(const SCEV *S) {
// Compute an insertion point for this SCEV object. Hoist the instructions
// as far out in the loop nest as possible.
@@ -1637,7 +1643,27 @@ Value *SCEVExpander::expand(const SCEV *S) {
Builder.SetInsertPoint(InsertPt);
// Expand the expression into instructions.
- Value *V = visit(S);
+ SetVector<Value *> *Set = SE.getSCEVValues(S);
+ Value *V = nullptr;
+ // If the expansion is in LSRMode, and the SCEV contains any sub scAddRecExpr
+ // type SCEV, it will be expanded literally, to prevent LSR's transformed SCEV
+ // from being reverted.
+ if (!(LSRMode && SE.containsAddRecurrence(S))) {
+ // If S is scConstant, it may be worse to reuse an existing Value.
+ if (S->getSCEVType() != scConstant && Set) {
+ // Choose a Value from the set which dominates the insertPt.
+ for (auto const &Ent : *Set) {
+ if (Ent && isa<Instruction>(Ent) && S->getType() == Ent->getType() &&
+ cast<Instruction>(Ent)->getFunction() == InsertPt->getFunction() &&
+ SE.DT.dominates(cast<Instruction>(Ent), InsertPt)) {
+ V = Ent;
+ break;
+ }
+ }
+ }
+ }
+ if (!V)
+ V = visit(S);
// Remember the expanded value for this SCEV at this location.
//
OpenPOWER on IntegriCloud