[PATCH] D39171: AMDGPU: Handle s_buffer_load_dword hazard on SI

Marek Olšák via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 24 02:47:04 PDT 2017


mareko added inline comments.


================
Comment at: lib/Target/AMDGPU/GCNHazardRecognizer.cpp:347
+
+  // This fixes what appears to be undocumented hardware behavior in SI where
+  // s_mov writing a descriptor and s_buffer_load_dword reading the descriptor
----------------
arsenm wrote:
> nhaehnle wrote:
> > This could be merged with the previous loop, right?
> Do you mean just SI? Needs a subtarget check? 
This code is only executed on SI.


================
Comment at: lib/Target/AMDGPU/GCNHazardRecognizer.cpp:354
+  // probably never encountered in the closed-source land.
+  if (SMRD->getOpcode() == AMDGPU::S_BUFFER_LOAD_DWORD_IMM ||
+      SMRD->getOpcode() == AMDGPU::S_BUFFER_LOAD_DWORDX2_IMM ||
----------------
arsenm wrote:
> Probably should avoid switch with something like isSMRD() && has buffer operand
Not sure if there is a way to check if an opcode has a buffer operand. It looks like not.


================
Comment at: test/CodeGen/AMDGPU/smrd.ll:93
+; GCN-DAG: s_mov_b32 s0, 0
+; SI-NEXT: nop 3
+; GCN-NEXT: s_buffer_load_dword s0, s[0:3], 0x0
----------------
nhaehnle wrote:
> Please add a NOTSI-NOT-NEXT line as well (or CIVIGFX9-NOT-NEXT?)
I think GCN-NEXT already ensures that there can't be any s_nop.


https://reviews.llvm.org/D39171





More information about the llvm-commits mailing list