================ @@ -660,42 +660,136 @@ Non-Integral Pointer Type Note: non-integral pointer types are a work in progress, and they should be considered experimental at this time. -LLVM IR optionally allows the frontend to denote pointers in certain address -spaces as "non-integral" via the :ref:`datalayout string<langref_datalayout>`. -Non-integral pointer types represent pointers that have an *unspecified* bitwise -representation; that is, the integral representation may be target dependent or -unstable (not backed by a fixed integer). +For most targets, the pointer representation is a direct mapping from the +bitwise representation to the address of the underlying memory allocation. +Such pointers are considered "integral", and any pointers where the +representation is not just an integer address are called "non-integral". + +Non-integral pointers have at least one of the following three properties: + +* the pointer representation contains non-address bits +* the pointer representation is unstable (may changed at any time in a + target-specific way) +* the pointer representation has external state + +These properties (or combinations thereof) can be applied to pointers via the +:ref:`datalayout string<langref_datalayout>`. + +The exact implications of these properties are target-specific. The following +subsections describe the IR semantics and restrictions to optimization passes +for each of these properties. + +Pointers with non-address bits +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Pointers in this address space have a bitwise representation that not only +has address bits, but also some other target-specific metadata. +In most cases pointers with a non-address bits 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 unless all the non-address bits are also recreated +correctly in a target-specific way. +Since the address width such a pointer is not equal to the bitwise +representation, extracting the address will need to truncate to the index width +of the pointer. + +An example of pointers with non-address bits are the AMDGPU buffer descriptors +which are 160 bits: a 128-bit fat pointer and a 32-bit offset. +Similarly, CHERI capabilities contain a 32 or 64 bit address as well as the +same number of metadata bits, but unlike the AMDGPU buffer descriptors they have +external state in addition to non-address bits. + + +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 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 integral (i.e., normal) pointers in that they convert integers to and from -corresponding pointer types, but there are additional implications to be -aware of. Because the bit-representation of a non-integral pointer may -not be stable, two identical casts of the same operand may or may not +corresponding pointer types, but there are additional implications to be aware +of. + +For "unstable" pointer representations, the bit-representation of the pointer +may not be stable, so two identical casts of the same operand may or may not return the same value. Said differently, the conversion to or from the -non-integral type depends on environmental state in an implementation +"unstable" pointer type depends on environmental state in an implementation defined manner. - ---------------- resistor wrote:
Probably want to keep the paragraph break? https://github.com/llvm/llvm-project/pull/105735 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
