[PATCH] D124246: [AMDGPU] Adjust wave priority based on VMEM instructions to avoid duty-cycling.

Jay Foad via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 26 05:14:27 PDT 2022


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

LGTM, thanks!



================
Comment at: llvm/lib/Target/AMDGPU/AMDGPUSetWavePriority.cpp:95
+    return false;
+
+  const GCNSubtarget &ST = MF.getSubtarget<GCNSubtarget>();
----------------
kosarev wrote:
> foad wrote:
> > I think it only makes sense to run this pass on kernels (i.e. the entry point of a wave), not on subfunctions, so you should bail out if `!AMDGPU::isKernel(MF.getFunction().getCallingConv())` or similar.
> Would `AMDGPU::isEntryFunctionCC()` be the right function for that?
Oh yes, isEntry* looks more appropriate than isKernel*.


================
Comment at: llvm/lib/Target/AMDGPU/AMDGPUSetWavePriority.cpp:136
+
+    if (CanLowerPriorityDirectlyInPredecessors(MBB, MBBInfos)) {
+      for (MachineBasicBlock *Pred : MBB.predecessors()) {
----------------
kosarev wrote:
> foad wrote:
> > A very minor point: you only lower priority in any predecessor if you can do it in all predecessors. Would it make sense to lower priority in some predecessors even if you can't do it in all of them?
> Yeah, good question. My analysis here is that while we know that would cost us extra time executing the `s_setprio 0` in `MBB` when control comes from one of such predecessors, I presently do not have any evidence at hand that that would help cases considered critical or at least important. The thinking therefore was that strategically we might prefer let the problem, if there is any, reveal itself and via that get a concrete reproducer, rather than to speculate early and never know for sure if it's actually necessary.
> 
> I probably should clarify that I see this patch as an attempt to introduce a reliable ground for developing our understanding of the nature of the original issue (which I guess may take some time testing and collecting relevant use cases), and not an implementation that tries to do the best thing for all theoretically possible cases right away.
OK!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124246



More information about the llvm-commits mailing list