[llvm] [LoopVectorize] Refine runtime memory check costs when there is an outer loop (PR #76034)

[David Sherwood via llvm-commits]

================
@@ -2091,16 +2091,45 @@ class GeneratedRTChecks {
         LLVM_DEBUG(dbgs() << "  " << C << "  for " << I << "\n");
         RTCheckCost += C;
       }
-    if (MemCheckBlock)
+    if (MemCheckBlock) {
+      InstructionCost MemCheckCost = 0;
       for (Instruction &I : *MemCheckBlock) {
         if (MemCheckBlock->getTerminator() == &I)
           continue;
         InstructionCost C =
             TTI->getInstructionCost(&I, TTI::TCK_RecipThroughput);
         LLVM_DEBUG(dbgs() << "  " << C << "  for " << I << "\n");
-        RTCheckCost += C;
+        MemCheckCost += C;
+      }
+
+      // If the runtime memory checks are being created inside an outer loop
+      // we should find out if these checks are outer loop invariant. If so,
+      // the checks will be hoisted out and so the effective cost will reduce
+      // according to the outer loop trip count.
+      if (OuterLoop) {
+        ScalarEvolution *SE = MemCheckExp.getSE();
+        const SCEV *Cond = SE->getSCEV(MemRuntimeCheckCond);
----------------
david-arm wrote:

So I did think about that, but I chose not to do that for a couple of reasons:

1. I assume that getting SCEVs is quite expensive, unless they've already been cached before. So I was worried about the increase in compilation time by checking each instruction.
2. Even if a particular instruction in the sequence is invariant, there is no guarantee it will be hoisted if the use is not invariant for some reason. So I thought the most convincing case was when the final condition was invariant as that likely means the whole sequence will be hoisted.

I'm happy to refine this algorithm further if you still think it's worth the extra compilation time and the risk of under-estimating the cost for instructions that don't get hoisted?

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