From 917d815d4ee4b545f1d8a34ee6edefca51f2e978 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nicolai=20H=C3=A4hnle?= Date: Fri, 7 Nov 2025 10:10:59 -0800 Subject: [PATCH] AMDGPU: Preliminary documentation for named barriers (#165502) --- llvm/docs/AMDGPUUsage.rst | 45 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst index 30b22a4a6d60..30b24b2f6f03 100644 --- a/llvm/docs/AMDGPUUsage.rst +++ b/llvm/docs/AMDGPUUsage.rst @@ -1180,6 +1180,51 @@ is conservatively correct for OpenCL. other operations within the same address space. ======================= =================================================== +Target Types +------------ + +The AMDGPU backend implements some target extension types. + +.. _amdgpu-types-named-barriers: + +Named Barriers +~~~~~~~~~~~~~~ + +Named barriers are fixed function hardware barrier objects that are available +in gfx12.5+ in addition to the traditional default barriers. + +In LLVM IR, named barriers are represented by global variables of type +``target("amdgcn.named.barrier", 0)`` in the LDS address space. Named barrier +global variables do not occupy actual LDS memory, but their lifetime and +allocation scope matches that of global variables in LDS. Programs in LLVM IR +refer to named barriers using pointers. + +The following named barrier types are supported in global variables, defined +recursively: + +* a single, standalone ``target("amdgcn.named.barrier", 0)`` +* an array of supported types +* a struct containing a single element of supported type + +.. code-block:: llvm + + @bar = addrspace(3) global target("amdgcn.named.barrier", 0) undef + @foo = addrspace(3) global [2 x target("amdgcn.named.barrier", 0)] undef + @baz = addrspace(3) global { target("amdgcn.named.barrier", 0) } undef + + ... + + %foo.i = getelementptr [2 x target("amdgcn.named.barrier", 0)], ptr addrspace(3) @foo, i32 0, i32 %i + call void @llvm.amdgcn.s.barrier.signal.var(ptr addrspace(3) %foo.i, i32 0) + +Named barrier types may not be used in ``alloca``. + +Named barriers do not have an underlying byte representation. +It is undefined behavior to use a pointer to any part of a named barrier object +as the pointer operand of a regular memory access instruction or intrinsic. +Pointers to named barrier objects are intended to be used with dedicated +intrinsics. Reading from or writing to such pointers is undefined behavior. + LLVM IR Intrinsics ------------------