[llvm] [AMDGPU][RA] Avoid pending scheduler candidates near unified VGPR occupancy limits (PR #220975)

[Yoonseo Choi via llvm-commits]

================
@@ -1832,6 +1837,32 @@ bool GCNSchedStage::initGCNRegion() {
 
   PressureBefore = DAG.Pressure[RegionIdx];
 
+  S.AllowPendingCandidates = true;
+
+  // Only adjust the initial max-occupancy schedule, and do not override the
+  // explicit scheduling policy of an IGLP region.
+  if (StageID == GCNSchedStageID::OccInitialSchedule && ST.hasGFX90AInsts() &&
+      !DAG.RegionsWithIGLPInstrs[RegionIdx]) {
+    unsigned DynamicVGPRBlockSize = MFI.getDynamicVGPRBlockSize();
+    unsigned RegionOccupancy =
+        std::min(DAG.MinOccupancy,
+                 PressureBefore.getOccupancy(ST, DynamicVGPRBlockSize));
+
+    // Pending candidates may extend live ranges. Round the estimate to the
+    // hardware allocation granule and keep the final block for the current
+    // occupancy in reserve. At one wave there is no lower occupancy to protect.
+    if (RegionOccupancy > 1) {
+      unsigned UnifiedVGPRPressure =
+          PressureBefore.getVGPRNum(/*UnifiedVGPRFile=*/true);
+      unsigned EstimatedUnifiedVGPRPressure =
+          alignTo(UnifiedVGPRPressure + MaxVGPRPressureInc + S.ErrorMargin,
+                  ST.getVGPRAllocGranule(DynamicVGPRBlockSize));
+      unsigned MaxVGPRs =
+          ST.getMaxNumVGPRs(RegionOccupancy, DynamicVGPRBlockSize);
+      S.AllowPendingCandidates = EstimatedUnifiedVGPRPressure < MaxVGPRs;
----------------
yoonseoch wrote:

Does not allowing pending candidate usually tend to reduce live ranges? Or was it the case specifically for the bug? 

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