[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)

Alexander Richardson via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Fri Oct 25 12:51:27 PDT 2024 

https://github.com/arichardson updated https://github.com/llvm/llvm-project/pull/105735

>From e4bd1181d160b8728e7d4158417a83e183bd1709 Mon Sep 17 00:00:00 2001
From: Alex Richardson <alexrichardson at google.com>
Date: Thu, 22 Aug 2024 14:36:04 -0700
Subject: [PATCH 1/2] fix indentation in langref

Created using spr 1.3.6-beta.1
---
 llvm/docs/LangRef.rst | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 200224c78be004..1a59fba65815cc 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -3103,19 +3103,19 @@ as follows:
 ``A<address space>``
     Specifies the address space of objects created by '``alloca``'.
     Defaults to the default address space of 0.
-``p[<flags>][n]:<size>:<abi>[:<pref>][:<idx>]``
+``p[<flags>][<address space>]:<size>:<abi>[:<pref>][:<idx>]``
     This specifies the *size* of a pointer and its ``<abi>`` and
     ``<pref>``\erred alignments for address space ``n``. ``<pref>`` is optional
     and defaults to ``<abi>``. The fourth parameter ``<idx>`` is the size of the
     index that used for address calculation, which must be less than or equal
     to the pointer size. If not
     specified, the default index size is equal to the pointer size. All sizes
-    are in bits. The address space, ``n``, is optional, and if not specified,
-    denotes the default address space 0. The value of ``n`` must be
-    in the range [1,2^24).
+    are in bits. The ``<address space>``, is optional, and if not specified,
+    denotes the default address space 0. The value of ``<address space>`` must
+    be in the range [1,2^24).
     The optional``<flags>`` are used to specify properties of pointers in this
-address space: the character ``u`` marks pointers as having an unstable
-    representation and ```n`` marks pointers as non-integral (i.e. having
+    address space: the character ``u`` marks pointers as having an unstable
+    representation and ``n`` marks pointers as non-integral (i.e. having
     additional metadata). See :ref:`Non-Integral Pointer Types <nointptrtype>`.
 
 ``i<size>:<abi>[:<pref>]``

>From db97145d3a653f2999b5935f9b1cb4550230689d Mon Sep 17 00:00:00 2001
From: Alex Richardson <alexrichardson at google.com>
Date: Fri, 25 Oct 2024 12:51:11 -0700
Subject: [PATCH 2/2] include feedback

Created using spr 1.3.6-beta.1
---
 llvm/docs/LangRef.rst             | 30 +++++++++++++++++-------------
 llvm/include/llvm/IR/DataLayout.h |  8 ++++----
 2 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index c137318af678b6..3c3d0e0b4ab8ee 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -659,7 +659,7 @@ LLVM IR optionally allows the frontend to denote pointers in certain address
 spaces as "non-integral" or "unstable" (or both "non-integral" and "unstable")
 via the :ref:`datalayout string<langref_datalayout>`.
 
-These exact implications of these properties are target-specific, but the
+The exact implications of these properties are target-specific, but the
 following IR semantics and restrictions to optimization passes apply:
 
 Unstable pointer representation
@@ -668,7 +668,7 @@ Unstable pointer representation
 Pointers in this address space have an *unspecified* bitwise representation
 (i.e. not backed by a fixed integer). The bitwise pattern of such pointers is
 allowed to change in a target-specific way. For example, this could be a pointer
-type used for with copying garbage collection where the garbage collector could
+type used with copying garbage collection where the garbage collector could
 update the pointer at any time in the collection sweep.
 
 ``inttoptr`` and ``ptrtoint`` instructions have the same semantics as for
@@ -705,10 +705,10 @@ representation of the pointer.
 Non-integral pointer representation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Pointers are not represented as an address, but may instead include
+Pointers are not represented as just an address, but may instead include
 additional metadata such as bounds information or a temporal identifier.
 Examples include AMDGPU buffer descriptors with a 128-bit fat pointer and a
-32-bit offset or CHERI capabilities that contain bounds, permissions and an
+32-bit offset, or CHERI capabilities that contain bounds, permissions and an
 out-of-band validity bit. In general, these pointers cannot be re-created
 from just an integer value.
 
@@ -716,23 +716,25 @@ In most cases pointers with a non-integral representation behave exactly the
 same as an integral pointer, the only difference is that it is not possible to
 create a pointer just from an address.
 
-"Non-integral" pointers also impose restrictions on the optimizer, but in
-general these are less restrictive than for "unstable" pointers. The main
+"Non-integral" pointers also impose restrictions on transformation passes, but
+in general these are less restrictive than for "unstable" pointers. The main
 difference compared to integral pointers is that ``inttoptr`` instructions
 should not be inserted by passes as they may not be able to create a valid
 pointer. This property also means that ``inttoptr(ptrtoint(x))`` cannot be
 folded to ``x`` as the ``ptrtoint`` operation may destroy the necessary metadata
 to reconstruct the pointer.
-Additionaly, since there could be out-of-band state, it is also not legal to
+Additionally, since there could be out-of-band state, it is also not legal to
 convert a load/store of a non-integral pointer type to a load/store of an
-integer type with same bitwidth as that may not copy all the state.
-However, it is legal to use appropriately aligned ``llvm.memcpy`` and
-``llvm.memmove`` for copies of non-integral pointers as long as these are not
-converted into integer operations.
+integer type with same bitwidth, as that may not copy all the state.
+However, it is legal to use appropriately-aligned ``llvm.memcpy`` and
+``llvm.memmove`` for copies of non-integral pointers.
+NOTE: Lowering of ``llvm.memcpy`` containing non-integral pointer types must use
+appropriately-aligned and sized types instead of smaller integer types.
 
 Unlike "unstable" pointers, the bit-wise representation is stable and
-``ptrtoint(x)`` always yields a deterministic values.
-This means optimizer is still permitted to insert new ``ptrtoint`` instructions.
+``ptrtoint(x)`` always yields a deterministic value.
+This means transformation passes are still permitted to insert new ``ptrtoint``
+instructions.
 However, it is important to note that ``ptrtoint`` may not yield the same value
 as storing the pointer via memory and reading it back as an integer, even if the
 bitwidth of the two types matches (since ptrtoint could involve some form of
@@ -12187,6 +12189,8 @@ If ``value`` is smaller than ``ty2`` then a zero extension is done. If
 ``value`` is larger than ``ty2`` then a truncation is done. If they are
 the same size, then nothing is done (*no-op cast*) other than a type
 change.
+For :ref:`non-integral pointers <_nointptrtype>` the ``ptrtoint`` instruction
+may involve additional transformations beyond truncations or extension.
 
 Example:
 """"""""
diff --git a/llvm/include/llvm/IR/DataLayout.h b/llvm/include/llvm/IR/DataLayout.h
index ca185bfec851a8..206abcdbea0a34 100644
--- a/llvm/include/llvm/IR/DataLayout.h
+++ b/llvm/include/llvm/IR/DataLayout.h
@@ -357,8 +357,8 @@ class DataLayout {
   /// instructions operating on pointers of this address space.
   /// TODO: remove this function after migrating to finer-grained properties.
   bool isNonIntegralAddressSpace(unsigned AddrSpace) const {
-    const PointerSpec &PS = getPointerSpec(AddrSpace);
-    return PS.HasNonIntegralRepresentation || PS.HasUnstableRepresentation;
+    return hasUnstableRepresentation(AddrSpace) ||
+           hasNonIntegralRepresentation(AddrSpace);
   }
 
   /// Returns whether this address space has an "unstable" pointer
@@ -390,8 +390,8 @@ class DataLayout {
   /// representations (hasUnstableRepresentation()) unless the pass knows it is
   /// within a critical section that retains the current representation.
   bool shouldAvoidIntToPtr(unsigned AddrSpace) const {
-    const PointerSpec &PS = getPointerSpec(AddrSpace);
-    return PS.HasNonIntegralRepresentation || PS.HasUnstableRepresentation;
+    return hasUnstableRepresentation(AddrSpace) ||
+           hasNonIntegralRepresentation(AddrSpace);
   }
 
   /// Returns whether passes should avoid introducing `ptrtoint` instructions

More information about the llvm-branch-commits mailing list