Add a profitability heuristic to enable runtime unrolling of multi-exit loop:
There can be atmost two unique exit blocks for the loop and the second
exit block should be a deoptimizing block. Also, there can be one other exiting block
other than the latch exiting block. The reason for the latter is so that we limit the number of
branches in the unrolled code to being at most the unroll factor.
Deoptimizing blocks are rarely taken so these additional number of branches
created due to the unrolling are predictable, since one of their target is the
deopt block.
Details
Diff Detail
- Build Status
Buildable 8200 Build 8200: arc lint + arc unit
Event Timeline
lib/Transforms/Utils/LoopUnrollRuntime.cpp | ||
---|---|---|
435 | Code structure wise, I'd recommend splitting this function into two: one which checks *legality* and one which given a legal case, checks profitability. Mixing the two needlessly is just confusing. This could in fact be done as an NFC change. | |
467 | Why did you chose this particular heuristic? What other options did you consider? (some of this should be in the code itself) |
lib/Transforms/Utils/LoopUnrollRuntime.cpp | ||
---|---|---|
435 | I had thought of this approach, but the main problem is that in the caller, there's the chance the user calls profitability without safety checks being done. Granted we can assert for that in the profitability check, but it's expensive. Perhaps I can place it under an EXPENSIVE_CHECKS option. | |
467 | will add details. |
Code structure wise, I'd recommend splitting this function into two: one which checks *legality* and one which given a legal case, checks profitability. Mixing the two needlessly is just confusing.
This could in fact be done as an NFC change.