Switch to a very conservative heuristic for determining when loop-unswitching

will be profitable.  This is mainly to remove some cases where excessive
unswitching would result in long compile times and/or huge generated code.

Once someone comes up with a better heuristic that avoids these cases, this
should be switched out.

llvm-svn: 28962

1 files changed, 5 insertions, 5 deletions

diff --git a/llvm/lib/Transforms/Scalar/LoopUnswitch.cpp b/llvm/lib/Transforms/Scalar/LoopUnswitch.cpp
index 945803f0afc..b3003845d4c 100644
--- a/llvm/lib/Transforms/Scalar/LoopUnswitch.cpp
+++ b/llvm/lib/Transforms/Scalar/LoopUnswitch.cpp
@@ -333,11 +333,11 @@ unsigned LoopUnswitch::getLoopUnswitchCost(Loop *L, Value *LIC) {
   if (IsTrivialUnswitchCondition(L, LIC))
     return 0;
   
-  // If the loop is really large (over twice our threshold) don't even consider
-  // unswitching it.  This will produce a really large loop with lots of empty
-  // blocks.
-  if (L->getBlocks().size() > 2*Threshold)
-    return 2*Threshold;
+  // FIXME: This is really overly conservative.  However, more liberal 
+  // estimations have thus far resulted in excessive unswitching, which is bad
+  // both in compile time and in code size.  This should be replaced once
+  // someone figures out how a good estimation.
+  return L->getBlocks().size();
   
   unsigned Cost = 0;
   // FIXME: this is brain dead.  It should take into consideration code