[LoopRotate] Bump rotation-max-header-size to 64

[lebedev.ri]

Summary

Currently, rotation-max-header-size is at 16, and it was always that way since the beginning (rL35714).
It is not very obvious (to me?) what reasoning is behind this threshold,
is it there to cap the maximal amount of work to be done to rotate the loop,
to cap the amount of instruction number growth, other?

But i think, threshold of 16 could use adjustment.

In particular, i've identified these loops here as not being rotated,
because they have more instructions than allowed (16 < x < 64, ~50).
That, in turn, prevents vectorizer from dealing with them,
which is not optimal since they should be vectorizable.

On my benchmarks, i'm not seeing any perf impact from this change.
And yes, those loops in question still aren't being vectorized, there are more issues.

llvm-compile-time-tracker is also not very unhappy with this:
http://llvm-compile-time-tracker.com/compare.php?from=07c4c7e7959b7fd09830bbdf4dcd533e98aa45ab&to=b40c8ea61a4bea615f2b3e1bbd0eaa67b7a13b44&stat=instructions
It clearly affects those tests, because

• there's pretty small +0.01 .. +0.05% compile-time regression
• this causes, on average, +0.03% size-text increase

So i'm wondering, what is the procedure here, would this be a reasonable change?

[fhahn]

• there's pretty small (+0.01 .. +0.05% compile-time regression)
• this causes, on average, +0.03% size-text increase

So i'm wondering, what is the procedure here, would this be a reasonable change?

I think the cap is mostly there to guard against unnecessary code size increases.

It would be interesting to see what the impact on code size would be with -Os across more than the ctmark tests. I think for -Oz we already force the header size to 0, but I am not sure if it would be great to add another -Os threshold.

[lebedev.ri]

In D83663#2146895, @fhahn wrote:

• there's pretty small (+0.01 .. +0.05% compile-time regression)
• this causes, on average, +0.03% size-text increase

So i'm wondering, what is the procedure here, would this be a reasonable change?

I think the cap is mostly there to guard against unnecessary code size increases.

Aha.

It would be interesting to see what the impact on code size would be with -Os across more than the ctmark tests. I think for -Oz we already force the header size to 0, but I am not sure if it would be great to add another -Os threshold.

I did indeed think about -Os/-Oz cases, and i indeed suspect this might not be beneficial for them.
I'm fully okay with keeping 16 for -Os.

But sadly i'm rather unfamiliar wit them, so i'm not sure i'm in position to actually assess the effects for -Os.

[lebedev.ri]

I'm not 100% sure, but possibly D84108 will fix most of the motivational code patterns.

llvm/lib/Transforms/Scalar/LoopRotation.cpp

 #include "llvm/Transforms/Scalar/LoopPassManager.h"
 #include "llvm/Transforms/Utils/LoopRotationUtils.h"
 #include "llvm/Transforms/Utils/LoopUtils.h"
 using namespace llvm;
 
 #define DEBUG_TYPE "loop-rotate"
 
 static cl::opt<unsigned> DefaultRotationThreshold(
-    "rotation-max-header-size", cl::init(16), cl::Hidden,
+    "rotation-max-header-size", cl::init(64), cl::Hidden,
     cl::desc("The default maximum header size for automatic loop rotation"));
 
 LoopRotatePass::LoopRotatePass(bool EnableHeaderDuplication)
     : EnableHeaderDuplication(EnableHeaderDuplication) {}
 
 PreservedAnalyses LoopRotatePass::run(Loop &L, LoopAnalysisManager &AM,
                                       LoopStandardAnalysisResults &AR,
                                       LPMUpdater &) {