[PATCH] D151997: [AMDGPU] Document amdgpu_cs_chain[_preserve] CCs. NFC

Nicolai Hähnle via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 6 04:47:06 PDT 2023


nhaehnle added a reviewer: t-tye.
nhaehnle added a subscriber: t-tye.
nhaehnle added inline comments.


================
Comment at: llvm/docs/AMDGPUUsage.rst:1111-1112
+                                     All counters (``lgkmcnt``, ``vmcnt``, ``storecnt``, etc.) are presumed in an
+                                     unknown state at function entry. Waits for regular memory counters are not
+                                     inserted as part of an ``llvm.amdgcn.cs.chain`` sequence in the function epilog.
+                                     However, we add waits for errata / hardware workarounds in the epilog:
----------------
foad wrote:
> I feel like this is missing some context. What is "an llvm.amdgcn.cs.chain sequence in the function epilog"???
It's a new intrinsic that belongs to the same set of changes, so while the context is missing from this patch, I think it's fair to let it be added implicitly by the change that adds the intrinsic.


================
Comment at: llvm/docs/AMDGPUUsage.rst:1113-1118
+                                     However, we add waits for errata / hardware workarounds in the epilog:
+
+                                     * On gfx11+, the function epilog waits for any scratch stores to be confirmed. This
+                                       works around the issue that we must wait for scratch stores before sending a
+                                       ``MSG_DEALLOC_VGPRS`` message.
+                                     * Additional waits may be required (e.g. ``s_waitcnt_depctr``).
----------------
foad wrote:
> I'm not sure any of this belongs in a calling convention description. The dealloc_vgprs thing applies to all kernels regardless of calling convention, but probably doesn't need to be documented to the end user anyway.
It is relevant if anybody wanted to try writing compatible code via some non-LLVM mechanism. @t-tye may have opinions on this as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151997



More information about the llvm-commits mailing list