Changes in directory llvm/lib/Transforms/Scalar:
LoopUnswitch.cpp updated: 1.43 -> 1.44
---
Log message:
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.
---
Diffs of the changes: (+5 -5)
LoopUnswitch.cpp | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
Index: llvm/lib/Transforms/Scalar/LoopUnswitch.cpp
diff -u llvm/lib/Transforms/Scalar/LoopUnswitch.cpp:1.43
llvm/lib/Transforms/Scalar/LoopUnswitch.cpp:1.44
--- llvm/lib/Transforms/Scalar/LoopUnswitch.cpp:1.43 Wed Jun 28 11:38:55 2006
+++ llvm/lib/Transforms/Scalar/LoopUnswitch.cpp Wed Jun 28 12:47:50 2006
@@ -333,11 +333,11 @@
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
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
