[llvm-branch-commits] [llvm] [AMDGPU] Add synthetic apertures and use them for barriers (PR #204127)

[Pierre van Houtryve via llvm-branch-commits]

================
@@ -1206,17 +1211,51 @@ supported for the ``amdgcn`` target.
   have a value corresponding to a valid barrier ID on the target.
   Otherwise, the behavior is undefined
 
-  These pointers do not have a corresponding hardware aperture but safe round-tripping
-  through the generic address space is still possible. Attempting to dereference a
-  generic pointer derived from a barrier pointer is undefined behavior.
-
 **Streamout Registers**
   Dedicated registers used by the GS NGG Streamout Instructions. The register
   file is modelled as a memory in a distinct address space because it is indexed
   by an address-like offset in place of named registers, and because register
   accesses affect LGKMcnt. This is an internal address space used only by the
   compiler. Do not use this address space for IR pointers.
 
+.. _amdgpu-synthetic-apertures:
+
+Synthetic Apertures
+~~~~~~~~~~~~~~~~~~~
+
+*Synthetic apertures* are defined that enable safe roundtrips of pointers
+from special address spaces through the generic address space. Attempting to
+dereference generic pointers obtained in this way (using e.g. `load` or
+`store`) has undefined behavior. The following synthetic apertures are defined:
+
+.. table:: AMDGPU Synthetic Apertures
+   :name: amdgpu-synthetic-apertures-table
+   :widths: 40 20 40
+
+    ============ ====== ===============================================================
+    Name         Number Corresponding :ref:`Address Space<amdgpu-address-spaces-table>`
+    ============ ====== ===============================================================
+    BARRIER      1      Barrier
----------------
Pierre-vh wrote:

The high bits are just the LDS aperture, those are found using the register and depend on the arch, no ? There are no magic high bits here

The key is that the LDS aperture's lower 48 bits are always zero. Only the upper 16 are relevant. So we fill the lower 32 with the source address (like we do already for flat/private -> generic), and now, with this path, we have a system that writes to bits `[32:48)` 

Or do you mean that this should spell out the entire value that gets OR'd with the LDS apeture value (so something like `1 << 32` as a 64 bit hexadecimal number)

https://github.com/llvm/llvm-project/pull/204127