aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp
diff options
context:
space:
mode:
authorPhilip Reames <listmail@philipreames.com>2021-11-15 12:30:48 -0800
committerPhilip Reames <listmail@philipreames.com>2021-11-15 13:00:14 -0800
commit8f95e915cd48a04d720935e3b13c3eef116aeb57 (patch)
treefdc69711724947e70efa5ff6ac6e6c13533fd537 /llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp
parentbee8e203c636ef6a5dfdf907e13721b61cc8ba9e (diff)
downloadllvm-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.cpp10
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.