[PPC/LoopUnrollRuntime] Don't avoid high-cost trip count computation on the PPC/A2

On X86 (and similar OOO cores) unrolling is very limited, and even if the
runtime unrolling is otherwise profitable, the expense of a division to compute
the trip count could greatly outweigh the benefits. On the A2, we unroll a lot,
and the benefits of unrolling are more significant (seeing a 5x or 6x speedup
is not uncommon), so we're more able to tolerate the expense, on average, of a
division to compute the trip count.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237947 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Hal Finkel
2015-05-21 20:30:23 +00:00
parent 3b294b5753
commit 5368a26e16
2 changed files with 31 additions and 0 deletions

View File

@@ -187,6 +187,10 @@ void PPCTTIImpl::getUnrollingPreferences(Loop *L,
// The A2 is in-order with a deep pipeline, and concatenation unrolling
// helps expose latency-hiding opportunities to the instruction scheduler.
UP.Partial = UP.Runtime = true;
// We unroll a lot on the A2 (hundreds of instructions), and the benefits
// often outweigh the cost of a division to compute the trip count.
UP.AllowExpensiveTripCount = true;
}
BaseT::getUnrollingPreferences(L, UP);