================
@@ -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
----------------
arsenm wrote:

I'd expect this table to have the fully spelled out magic high bits 

https://github.com/llvm/llvm-project/pull/204127
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Reply via email to