Remove dead code, that I apparently wrote a while back. We seem to be doing well...
authorOwen Anderson <resistor@mac.com>
Mon, 17 Jan 2011 22:39:54 +0000 (22:39 +0000)
committerOwen Anderson <resistor@mac.com>
Mon, 17 Jan 2011 22:39:54 +0000 (22:39 +0000)
without whatever this was trying to do.  When/if someone has the time to do some empirical
evaluations, it might be worth it to figure out what this code was trying to do and see if
it's worth resurrecting/fixing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123684 91177308-0d34-0410-b5e6-96231b3b80d8

lib/Transforms/Scalar/LoopUnrollPass.cpp

index 90eb857c85e0ff799e4ac7b080ccf9276b0b90de..80b263a30cb8fa4aca4d05e279041fa91d0ec6f0 100644 (file)
@@ -99,21 +99,6 @@ static unsigned ApproximateLoopSize(const Loop *L, unsigned &NumCalls) {
   
   unsigned LoopSize = Metrics.NumInsts;
   
-  // If we can identify the induction variable, we know that it will become
-  // constant when we unroll the loop, so factor that into our loop size 
-  // estimate.
-  // FIXME: We have to divide by InlineConstants::InstrCost because the
-  // measure returned by CountCodeReductionForConstant is not an instruction
-  // count, but rather a weight as defined by InlineConstants.  It would 
-  // probably be a good idea to standardize on a single weighting scheme by
-  // pushing more of the logic for weighting into CodeMetrics.
-  if (PHINode *IndVar = L->getCanonicalInductionVariable()) {
-    unsigned SizeDecrease = Metrics.CountCodeReductionForConstant(IndVar);
-    // NOTE: Because SizeDecrease is a fuzzy estimate, we don't want to allow
-    // it to totally negate the cost of unrolling a loop.
-    SizeDecrease = SizeDecrease > LoopSize / 2 ? LoopSize / 2 : SizeDecrease;
-  }
-  
   // Don't allow an estimate of size zero.  This would allows unrolling of loops
   // with huge iteration counts, which is a compile time problem even if it's
   // not a problem for code quality.