[llvm] [AArch64] Cap upper-bound unrolling of loops with uncomputable trip counts (PR #205102)

[Igor Kirillov via llvm-commits]

================
@@ -6042,6 +6042,19 @@ void AArch64TTIImpl::getUnrollingPreferences(
 
   UP.UpperBound = true;
 
+  // A loop can have a small maximum trip count while SCEV still cannot
+  // form an exact backedge count - typically a data-dependent exit, e.g.
+  // shifting a value until it reaches zero. Unrolling such a loop trades one
+  // well-predicted backedge for a chain of rarely-taken exit branches, so hold
----------------
igogo-x86 wrote:

Agreed, reworded to make clear this is a conservative heuristic, not a claim that unrolling always loses. About `v=1`: at runtime, both versions execute a single conditional branch (the unrolled body leaves through the first exit test and the rest are never reached), so the cost there is static - six branch sites and the code growth instead of one. Where behaviour really diverges is when the length varies from call to call, and whether unrolling then helps depends on the distribution, which we can't know at compile time. The code growth is certain, and it measurably regressed sqlite3. Loops where a profile says otherwise can still be peeled (profile-guided peeling is deliberately unaffected)

https://github.com/llvm/llvm-project/pull/205102