[llvm] [AMDGPU][Scheduler] Scoring system for rematerialization candidates (PR #153092)

Matt Arsenault via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 18 13:04:42 PST 2025


================
@@ -2086,65 +2327,93 @@ void PreRARematStage::rematerialize() {
             assert((SR.LaneMask & UncoveredLanes).none());
         }
       }
+    }
 #endif
 
-      // The register is no longer a live-in in all regions but the one that
-      // contains the single use. In live-through regions, maximum register
-      // pressure decreases predictably so we can directly update it. In the
-      // using region, maximum RP may or may not decrease, so we will mark it
-      // for re-computation after all materializations have taken place.
-      LaneBitmask PrevMask = RegionLiveIns[Reg];
-      RegionLiveIns.erase(Reg);
-      RegMasks.insert({{I, Remat.RematMI->getOperand(0).getReg()}, PrevMask});
-      if (Remat.UseMI->getParent() != DAG.Regions[I].first->getParent())
-        DAG.Pressure[I].inc(Reg, PrevMask, LaneBitmask::getNone(), DAG.MRI);
-      else
-        RecomputeRP.insert(I);
+    // This save is guaranteed in regions in which the register is live-through
+    // and unused but optimistic in all other regions where the register is
+    // live.
+    RPTargets[I].saveReg(Reg, Remat.Mask, DAG.MRI);
+    DAG.LiveIns[I].erase(Reg);
+    DAG.RegionLiveOuts.getLiveRegsForRegionIdx(I).erase(Reg);
+    if (!Remat.isUnusedLiveThrough(I))
+      RecomputeRP.set(I);
+  }
+
+  DAG.deleteMI(Remat.DefRegion, &DefMI);
+  RescheduleRegions |= Remat.Live;
+}
+
+void PreRARematStage::rollback(const RollbackInfo &Rollback,
----------------
arsenm wrote:

I'm not a big fan of rollback. Avoiding making changes in the MIR is better. Making the change has side effects, like reordering register use lists, and renumbering slot indexes. Both of these things make reproducing issues with MIR much more difficult. It doesn't help that we do not have a way to serialize either of these things 

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


More information about the llvm-commits mailing list