[llvm] [RFC] IR: Define noalias.addrspace metadata (PR #102461)
Matt Arsenault via llvm-commits
llvm-commits at lists.llvm.org
Fri Aug 9 04:37:44 PDT 2024
================
@@ -8020,6 +8020,42 @@ 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}
+
+
+This is intended for use on targets with a notion of generic address
+spaces, which at runtime resolve to different physical memory
+spaces. The interpretation of the address space values is target
+specific. The behavior is undefined if the runtime memory address does
+resolve to an object defined in one of the indicated address spaces.
----------------
arsenm wrote:
I'm not exactly sure how to parse this question.
> when this metadata is used to specify an object is not in the generic address space
Do you mean, in the amdgpu case, !{i32 0, i32 1}?
> because the concrete address space any object is in will not be the generic address space?
We avoid creating objects in the generic address space (except functions), but it shouldn't really matter?
https://github.com/llvm/llvm-project/pull/102461
More information about the llvm-commits
mailing list