diff options
author | Philip Reames <listmail@philipreames.com> | 2021-11-15 12:30:48 -0800 |
---|---|---|
committer | Philip Reames <listmail@philipreames.com> | 2021-11-15 13:00:14 -0800 |
commit | 8f95e915cd48a04d720935e3b13c3eef116aeb57 (patch) | |
tree | fdc69711724947e70efa5ff6ac6e6c13533fd537 /llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp | |
parent | bee8e203c636ef6a5dfdf907e13721b61cc8ba9e (diff) | |
download | llvm-8f95e915cd48a04d720935e3b13c3eef116aeb57.zip llvm-8f95e915cd48a04d720935e3b13c3eef116aeb57.tar.gz llvm-8f95e915cd48a04d720935e3b13c3eef116aeb57.tar.bz2 |
[unroll-runtime] Relax two profitability limitations on multi-exit unrolling
This change is mostly about getting rid of some "uninteresting" cases in a follow on deeper heuristic change. If anyone sees actually interesting code differences out of this, please let me know. I'm not expecting this to have much impact at all.
Case 1 - With the single deoptimize non-latch exit, we can't have two exiting blocks sharing an exit block. We can only hit this with a poorly documented debug flag.
Case 2 - Why should we treat epilog cases differently from prolog cases? Or to say it differently, why should starting with a constant control whether a multiple exit loop gets unrolled?
Sorry for the lack of tests here. These are both *exceedingly* narrow cases in practice, and after a while trying, I couldn't come up with a test which did anything "useful" as opposed to simply exercise a random combination of force flags. Note that the legality cases for each are already exercised with force flags.
Diffstat (limited to 'llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp')
-rw-r--r-- | llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp | 10 |
1 files changed, 0 insertions, 10 deletions
diff --git a/llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp b/llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp index aca25be..a92cb6a 100644 --- a/llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp +++ b/llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp @@ -421,16 +421,6 @@ static bool canProfitablyUnrollMultiExitLoop( if (UnrollRuntimeMultiExit.getNumOccurrences()) return UnrollRuntimeMultiExit; - // TODO: We used to bail out for correctness (now fixed). Under what - // circumstances is this case profitable to allow? - if (!LatchExit->getSinglePredecessor()) - return false; - - // TODO: We used to bail out for correctness (now fixed). Under what - // circumstances is this case profitable to allow? - if (UseEpilogRemainder && L->getParentLoop()) - return false; - // The main pain point with multi-exit loop unrolling is that once unrolled, // we will not be able to merge all blocks into a straight line code. // There are branches within the unrolled loop that go to the OtherExits. |