[llvm] 8f95e91 - [unroll-runtime] Relax two profitability limitations on multi-exit unrolling

Philip Reames via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 15 13:00:21 PST 2021


Author: Philip Reames
Date: 2021-11-15T13:00:14-08:00
New Revision: 8f95e915cd48a04d720935e3b13c3eef116aeb57

URL: https://github.com/llvm/llvm-project/commit/8f95e915cd48a04d720935e3b13c3eef116aeb57
DIFF: https://github.com/llvm/llvm-project/commit/8f95e915cd48a04d720935e3b13c3eef116aeb57.diff

LOG: [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.

Added: 
    

Modified: 
    llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp

Removed: 
    


################################################################################
diff  --git a/llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp b/llvm/lib/Transforms/Utils/LoopUnrollRuntime.cpp
index aca25bed78b0..a92cb6a313d3 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.


        


More information about the llvm-commits mailing list