[PATCH] D134726: [AMDGPU][SetWavePriority] Fix dealing with MBBInfo records.

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 30 05:38:52 PDT 2022


arsenm accepted this revision.
arsenm added a comment.
This revision is now accepted and ready to land.

LGTM. I really hate insert by index operator.



================
Comment at: llvm/lib/Target/AMDGPU/AMDGPUSetWavePriority.cpp:131
         AtStart = false;
-        Info.NumVALUInstsAtStart = 0;
+        MBBInfos[MBB].NumVALUInstsAtStart = 0;
         MaxNumVALUInstsInMiddle = 0;
----------------
Move &Info down here to avoid 2 map lookups?


================
Comment at: llvm/lib/Target/AMDGPU/AMDGPUSetWavePriority.cpp:150-152
       SuccsMayReachVMEMLoad |= MBBInfos[Succ].MayReachVMEMLoad;
       NumFollowingVALUInsts =
           std::max(NumFollowingVALUInsts, MBBInfos[Succ].NumVALUInstsAtStart);
----------------
kosarev wrote:
> arsenm wrote:
> > kosarev wrote:
> > > These potentially invalidate `Info`.
> > Doesn't this imply it's reading uncomputed values for the successors? Don't those need to be computed for this to do something sensible?
> I understand where the edge to a successor is a back edge, we will examine its `MBBInfo` here before the main `post_order(&MF)` loop had a chance to compute it. Logic-wise that itself is not a problem because we ignore loops, but since such successors are new to `MBBInfos`, this invalidates `Info`.
Should this not ignore loops?


================
Comment at: llvm/lib/Target/AMDGPU/AMDGPUSetWavePriority.cpp:154
     }
     if (AtStart)
+      MBBInfos[MBB].NumVALUInstsAtStart += NumFollowingVALUInsts;
----------------
Ditto?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134726/new/

https://reviews.llvm.org/D134726



More information about the llvm-commits mailing list