[llvm] [GreedyRA] Improve RA for nested loop induction variables (PR #72093)

[David Green via llvm-commits]

================
@@ -767,10 +767,27 @@ bool RAGreedy::growRegion(GlobalSplitCandidate &Cand) {
     if (Cand.PhysReg) {
       if (!addThroughConstraints(Cand.Intf, NewBlocks))
         return false;
-    } else
-      // Provide a strong negative bias on through blocks to prevent unwanted
-      // liveness on loop backedges.
-      SpillPlacer->addPrefSpill(NewBlocks, /* Strong= */ true);
+    } else {
+      // Providing that the variable being spilled does not look like a loop
+      // induction variable, which is expensive to spill around and better
+      // pushed into a condition inside the loop if possible, provide a strong
+      // negative bias on through blocks to prevent unwanted liveness on loop
+      // backedges.
+      bool PrefSpill = true;
+      if (SA->looksLikeLoopIV() && NewBlocks.size() == 3) {
+        // NewBlocks==3 means we are (possible) adding a Header + start+end of
+        // two loop-internal blocks. If the block is indeed a header, don't make
+        // the newblocks as PrefSpill to allow the variable to be live in
+        // header<->latch.
+        MachineLoop *L = Loops->getLoopFor(MF->getBlockNumbered(NewBlocks[0]));
+        if (L && L->getHeader()->getNumber() == NewBlocks[0] &&
+            L == Loops->getLoopFor(MF->getBlockNumbered(NewBlocks[1])) &&
+            L == Loops->getLoopFor(MF->getBlockNumbered(NewBlocks[2])))
----------------
davemgreen wrote:

I was aiming for the three blocks in the bundle being the loop header plus start and end of two inner loop blocks, if I'm understanding the bundles correctly. It would represent an if condition in the loop. In the original case there are many more "through" blocks in the loop, I think upto 180, but the first bundle is just the header + 2 inner blocks.

There might be more than one block jumping to the latch. I could try and generalise it to any number of blocks so long as they are all in the loop, if you think that sounds better? That looks like it should be similar for perf/compile-time.

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