[llvm] [RFC] IR: Define noalias.addrspace metadata (PR #102461)

[Matt Arsenault via llvm-commits]

================
@@ -8021,6 +8021,43 @@ it will contain a list of ids, including the ids of the callsites in the
 full inline sequence, in order from the leaf-most call's id to the outermost
 inlined call.
 
+
+'``noalias.addrspace``' Metadata
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``noalias.addrspace`` metadata is used to identify memory
+operations which cannot access a range of address spaces. It is
+attached to memory instructions, including :ref:`atomicrmw
+<i_atomicrmw>`, :ref:`cmpxchg <i_cmpxchg>`, and :ref:`call <i_call>`
+instructions.
+
+This follows the same form as :ref:`range metadata <range-metadata>`,
+except the field entries must be of type `i32`. The interpretation is
+the same numeric address spaces as applied to IR values.
+
+Example:
+
+.. code-block:: llvm
+
+    ; %ptr cannot point to an object allocated in addrspace(5)
+    %rmw.valid = atomicrmw and ptr %ptr, i64 %value seq_cst, !noalias.addrspace !0
+
+    ; Undefined behavior. The underlying object is allocated in one of the listed
+    ; address spaces.
+    %alloca = alloca i64, addrspace(5)
+    %alloca.cast = addrspacecast ptr addrspace(5) %alloca to ptr
+    %rmw.ub = atomicrmw and ptr %alloca.cast, i64 %value seq_cst, !noalias.addrspace !0
+
+    !0 = !{i32 5, i32 6}
----------------
arsenm wrote:

This is only a way to add flexibility in the encoding for future use. There's no inherent meaning of consecutive address spaces.

In the current AMDGPU/PTX use cases, there's only one stack address space to consider. If in the future we wanted to reserve some range of address space values for software uses that may be allocated as stack, you could represent this without listing every possible value. Plus reusing all of the range parse and check code is nicer than needing to brute force search through a list of entries 

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