[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