[PATCH] D24451: [LoopUnroller] Replace UnrollingPreferences::Force with ForceMaxCount + SystemZ getUnrollingPreferences().

[Evgeny Stupachenko via llvm-commits]

evstupac added a comment.

> > If You need to control number of stores/branches you can limit MaxCount for all kinds of unroll. Or even better - calculate specific count for your architecture based on number of stores/branches.

> 

> 

> This is what the patch is doing, except it doesn't limit on branches for partial / runtime.


There are several cases when runtime unroll fails. More than one exit branch is only one reason. That means you are limiting force unroll count even if there are less than 3 exit branches.

What I suggested is to count exit branches (without a dependency on unroll type). Say there are N in the loop. Then if (N > 1), set  MaxCount to 3/(N - 1) without introducing ForceMaxCount.
That way if you have 2 or more exit branches - Runtime Unroll will fail, but Count will be not more than 3.
If you have 1 exit branch you will not affect MaxCount and proceed with RuntimeUnroll.
So basically the behavior would be the same but you'll not limit force unroll count by 3 when you have less than 3 exit branches.


================
Comment at: lib/Transforms/Utils/LoopUnroll.cpp:308
@@ -306,2 +307,3 @@
       RuntimeTripCount = false;
-    else
+      Count = std::min(Count, ForceMaxCount);
+    }
----------------
Even for SystemZ this is not good. And someone else in future could also use ForceMaxCount for his own architecture.
It would be good not to change Count in many places.



https://reviews.llvm.org/D24451