[llvm] [RFC] IR: Define noalias.addrspace metadata (PR #102461)
Harald van Dijk via llvm-commits
llvm-commits at lists.llvm.org
Sun Sep 8 12:29:06 PDT 2024
================
@@ -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}
----------------
hvdijk wrote:
Agreed, this is not obvious, I am only now realising I messed that up when I asked my question to clarify another aspect of this, and it went unnoticed.
Are ranges of address spaces, in general, a meaningful thing? I would not have assumed that current address space numbering is intended to be meaningful, there is no presumption that two address spaces being consecutive means they are any more or less likely to make sense to combine than two non-consecutive address spaces. And would excluding address spaces 5 and 7, but not 6, then require using two `!noalias.addrspace` annotations on the same instruction, or is there a better way? Whatever the answer is, could you add an example of that?
https://github.com/llvm/llvm-project/pull/102461
More information about the llvm-commits
mailing list