[llvm] r218971 - Revert r215343.
James Molloy
james.molloy at arm.com
Fri Oct 3 02:29:27 PDT 2014
Author: jamesm
Date: Fri Oct 3 04:29:24 2014
New Revision: 218971
URL: http://llvm.org/viewvc/llvm-project?rev=218971&view=rev
Log:
Revert r215343.
This was contentious and needs invesigation.
Removed:
llvm/trunk/test/Transforms/JumpThreading/jump_threading.ll
Modified:
llvm/trunk/lib/Analysis/LazyValueInfo.cpp
Modified: llvm/trunk/lib/Analysis/LazyValueInfo.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/LazyValueInfo.cpp?rev=218971&r1=218970&r2=218971&view=diff
==============================================================================
--- llvm/trunk/lib/Analysis/LazyValueInfo.cpp (original)
+++ llvm/trunk/lib/Analysis/LazyValueInfo.cpp Fri Oct 3 04:29:24 2014
@@ -545,31 +545,7 @@ bool LazyValueInfoCache::solveBlockValue
// cache needs updating, i.e. if we have solve a new value or not.
OverDefinedCacheUpdater ODCacheUpdater(Val, BB, BBLV, this);
- // Once this BB is encountered, Val's value for this BB will not be Undefined
- // any longer. When we encounter this BB again, if Val's value is Overdefined,
- // we need to compute its value again.
- //
- // For example, considering this control flow,
- // BB1->BB2, BB1->BB3, BB2->BB3, BB2->BB4
- //
- // Suppose we have "icmp slt %v, 0" in BB1, and "icmp sgt %v, 0" in BB3. At
- // the very beginning, when analyzing edge BB2->BB3, we don't know %v's value
- // in BB2, and the data flow algorithm tries to compute BB2's predecessors, so
- // then we know %v has negative value on edge BB1->BB2. And then we return to
- // check BB2 again, and at this moment BB2 has Overdefined value for %v in
- // BB2. So we should have to follow data flow propagation algorithm to get the
- // value on edge BB1->BB2 propagated to BB2, and finally %v on BB2 has a
- // constant range describing a negative value.
- //
- // In the mean time, limit the number of additional lowering lattice value to
- // avoid unjustified memory grows.
-
- if (LoweringOverdefinedTimes.count(BB) == 0)
- LoweringOverdefinedTimes.insert(std::make_pair(BB, 0));
- if ((!BBLV.isUndefined() && !BBLV.isOverdefined()) ||
- (BBLV.isOverdefined() &&
- (LoweringOverdefinedTimes[BB] > OverdefinedThreshold ||
- LoweringOverdefinedTimes.size() > OverdefinedBBThreshold))) {
+ if (!BBLV.isUndefined()) {
DEBUG(dbgs() << " reuse BB '" << BB->getName() << "' val=" << BBLV <<'\n');
// Since we're reusing a cached value here, we don't need to update the
Removed: llvm/trunk/test/Transforms/JumpThreading/jump_threading.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/JumpThreading/jump_threading.ll?rev=218970&view=auto
==============================================================================
--- llvm/trunk/test/Transforms/JumpThreading/jump_threading.ll (original)
+++ llvm/trunk/test/Transforms/JumpThreading/jump_threading.ll (removed)
@@ -1,33 +0,0 @@
-; RUN: opt < %s -jump-threading -S | FileCheck %s
-
-define i32 @test_jump_threading(i32* %arg1, i32 %arg2) {
-entry:
- %cmp = icmp slt i32 %arg2, 0
- br i1 %cmp, label %land.lhs.true, label %lor.rhs
-
-land.lhs.true:
- %ident = getelementptr inbounds i32 * %arg1, i64 0
- %0 = load i32* %ident, align 4
- %cmp1 = icmp eq i32 %0, 1
- br i1 %cmp1, label %lor.end, label %lor.rhs
-
-; CHECK: br i1 %cmp1, label %lor.end, label %lor.rhs.thread
-
-; CHECK: lor.rhs.thread:
-; CHECK-NEXT: br label %lor.end
-
-lor.rhs:
- %cmp2 = icmp sgt i32 %arg2, 0
- br i1 %cmp2, label %land.rhs, label %lor.end
-
-land.rhs:
- %ident3 = getelementptr inbounds i32 * %arg1, i64 0
- %1 = load i32* %ident3, align 4
- %cmp4 = icmp eq i32 %1, 2
- br label %lor.end
-
-lor.end:
- %2 = phi i1 [ true, %land.lhs.true ], [ false, %lor.rhs ], [ %cmp4, %land.rhs ]
- %lor.ext = zext i1 %2 to i32
- ret i32 %lor.ext
-}
More information about the llvm-commits
mailing list