[llvm] LoopVectorize: Set branch_weight for conditional branches (PR #72450)

[Matthias Braun via llvm-commits]

================
@@ -396,6 +398,19 @@ static cl::opt<bool> UseWiderVFIfCallVariantsPresent(
     cl::Hidden,
     cl::desc("Try wider VFs if they enable the use of vector variants"));
 
+// Likelyhood of bypassing the vectorized loop because assumptions about SCEV
+// variables not overflowing do not hold. See `emitSCEVChecks`.
+static constexpr uint32_t SCEVCheckBypassWeights[] = {1, 127};
+// Likelyhood of bypassing the vectorized loop because pointers overlap. See
+// `emitMemRuntimeChecks`.
+static constexpr uint32_t MemCheckBypassWeights[] = {1, 127};
+// Likelyhood of bypassing the vectorized loop because there are zero trips left
+// after prolog. See `emitIterationCountCheck`.
+static constexpr uint32_t MinItersBypassWeights[] = {1, 127};
+// Likelyhood of bypassing the vectorized loop because of zero trips necessary.
+// See `emitMinimumVectorEpilogueIterCountCheck`.
+static constexpr uint32_t EpilogueMinItersBypassWeights[] = {1, 127};
----------------
MatzeB wrote:

I think I may have confused this particular check with the very similar `MinItersBypassWeights` which tests whether the total amount of iterations is smaller than the loop count, which is something we cannot easily compute. But I think you are right in that this one is indeed the remainder of iterations after the vectorized body ran. Computing this based on the tripcount similar to what I am already doing for `InnerLoopVectorizer::completeLoopSkeleton()` makes sense. Will send a follow-up.

The number "127" itself has no real justification except that we know it should be a "big" number and that not annotating anything leaves us with a bad 50:50 default assumed by `BranchProbabilityInfo`. Whether the truth is closer to 64 or 256 or some other number I don't know.

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