@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
649649
650650.. _nointptrtype:
651651
652- Non-Integral Pointer Type
653- -------------------------
652+ Non-Integral and Unstable Pointer Types
653+ ---------------------------------------
654654
655- Note: non-integral pointer types are a work in progress, and they should be
656- considered experimental at this time.
655+ Note: non-integral/unstable pointer types are a work in progress, and they
656+ should be considered experimental at this time.
657657
658658LLVM IR optionally allows the frontend to denote pointers in certain address
659- spaces as "non-integral" via the :ref:`datalayout string<langref_datalayout>`.
660- Non-integral pointer types represent pointers that have an *unspecified* bitwise
661- representation; that is, the integral representation may be target dependent or
662- unstable (not backed by a fixed integer).
659+ spaces as "non-integral" or "unstable" (or both "non-integral" and "unstable")
660+ via the :ref:`datalayout string<langref_datalayout>`.
661+
662+ These exact implications of these properties are target-specific, but the
663+ following IR semantics and restrictions to optimization passes apply:
664+
665+ Unstable pointer representation
666+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
667+
668+ Pointers in this address space have an *unspecified* bitwise representation
669+ (i.e. not backed by a fixed integer). The bitwise pattern of such pointers is
670+ allowed to change in a target-specific way. For example, this could be a pointer
671+ type used for with copying garbage collection where the garbage collector could
672+ update the pointer at any time in the collection sweep.
663673
664674``inttoptr`` and ``ptrtoint`` instructions have the same semantics as for
665675integral (i.e. normal) pointers in that they convert integers to and from
666- corresponding pointer types, but there are additional implications to be
667- aware of. Because the bit-representation of a non-integral pointer may
668- not be stable, two identical casts of the same operand may or may not
676+ corresponding pointer types, but there are additional implications to be aware
677+ of.
678+
679+ For "unstable" pointer representations, the bit-representation of the pointer
680+ may not be stable, so two identical casts of the same operand may or may not
669681return the same value. Said differently, the conversion to or from the
670- non-integral type depends on environmental state in an implementation
682+ "unstable" pointer type depends on environmental state in an implementation
671683defined manner.
672-
673684If the frontend wishes to observe a *particular* value following a cast, the
674685generated IR must fence with the underlying environment in an implementation
675686defined manner. (In practice, this tends to require ``noinline`` routines for
676687such operations.)
677688
678689From the perspective of the optimizer, ``inttoptr`` and ``ptrtoint`` for
679- non-integral types are analogous to ones on integral types with one
690+ "unstable" pointer types are analogous to ones on integral types with one
680691key exception: the optimizer may not, in general, insert new dynamic
681692occurrences of such casts. If a new cast is inserted, the optimizer would
682693need to either ensure that a) all possible values are valid, or b)
683694appropriate fencing is inserted. Since the appropriate fencing is
684695implementation defined, the optimizer can't do the latter. The former is
685696challenging as many commonly expected properties, such as
686- ``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for non-integral types.
697+ ``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for "unstable" pointer types.
687698Similar restrictions apply to intrinsics that might examine the pointer bits,
688699such as :ref:`llvm.ptrmask<int_ptrmask>`.
689700
690- The alignment information provided by the frontend for a non-integral pointer
701+ The alignment information provided by the frontend for an "unstable" pointer
691702(typically using attributes or metadata) must be valid for every possible
692703representation of the pointer.
693704
705+ Non-integral pointer representation
706+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
707+
708+ Pointers are not represented as an address, but may instead include
709+ additional metadata such as bounds information or a temporal identifier.
710+ Examples include AMDGPU buffer descriptors with a 128-bit fat pointer and a
711+ 32-bit offset or CHERI capabilities that contain bounds, permissions and an
712+ out-of-band validity bit. In general, these pointers cannot be re-created
713+ from just an integer value.
714+
715+ In most cases pointers with a non-integral representation behave exactly the
716+ same as an integral pointer, the only difference is that it is not possible to
717+ create a pointer just from an address.
718+
719+ "Non-integral" pointers also impose restrictions on the optimizer, but in
720+ general these are less restrictive than for "unstable" pointers. The main
721+ difference compared to integral pointers is that ``inttoptr`` instructions
722+ should not be inserted by passes as they may not be able to create a valid
723+ pointer. This property also means that ``inttoptr(ptrtoint(x))`` cannot be
724+ folded to ``x`` as the ``ptrtoint`` operation may destroy the necessary metadata
725+ to reconstruct the pointer.
726+ Additionaly, since there could be out-of-band state, it is also not legal to
727+ convert a load/store of a non-integral pointer type to a load/store of an
728+ integer type with same bitwidth as that may not copy all the state.
729+ However, it is legal to use appropriately aligned ``llvm.memcpy`` and
730+ ``llvm.memmove`` for copies of non-integral pointers as long as these are not
731+ converted into integer operations.
732+
733+ Unlike "unstable" pointers, the bit-wise representation is stable and
734+ ``ptrtoint(x)`` always yields a deterministic values.
735+ This means optimizer is still permitted to insert new ``ptrtoint`` instructions.
736+ However, it is important to note that ``ptrtoint`` may not yield the same value
737+ as storing the pointer via memory and reading it back as an integer, even if the
738+ bitwidth of the two types matches (since ptrtoint could involve some form of
739+ arithmetic or strip parts of the non-integral pointer representation).
740+
694741.. _globalvars:
695742
696743Global Variables
@@ -3082,16 +3129,21 @@ as follows:
30823129``A<address space>``
30833130 Specifies the address space of objects created by '``alloca``'.
30843131 Defaults to the default address space of 0.
3085- ``p[n ]:<size>:<abi>[:<pref>][:<idx>]``
3132+ ``p[<flags>][<address space> ]:<size>:<abi>[:<pref>][:<idx>]``
30863133 This specifies the *size* of a pointer and its ``<abi>`` and
30873134 ``<pref>``\erred alignments for address space ``n``. ``<pref>`` is optional
30883135 and defaults to ``<abi>``. The fourth parameter ``<idx>`` is the size of the
30893136 index that used for address calculation, which must be less than or equal
30903137 to the pointer size. If not
30913138 specified, the default index size is equal to the pointer size. All sizes
3092- are in bits. The address space, ``n``, is optional, and if not specified,
3093- denotes the default address space 0. The value of ``n`` must be
3094- in the range [1,2^24).
3139+ are in bits. The ``<address space>``, is optional, and if not specified,
3140+ denotes the default address space 0. The value of ``<address space>`` must
3141+ be in the range [1,2^24).
3142+ The optional``<flags>`` are used to specify properties of pointers in this
3143+ address space: the character ``u`` marks pointers as having an unstable
3144+ representation and ``n`` marks pointers as non-integral (i.e. having
3145+ additional metadata). See :ref:`Non-Integral Pointer Types <nointptrtype>`.
3146+
30953147``i<size>:<abi>[:<pref>]``
30963148 This specifies the alignment for an integer type of a given bit
30973149 ``<size>``. The value of ``<size>`` must be in the range [1,2^24).
0 commit comments