================
@@ -15454,33 +15471,43 @@ The first index determines which element/field of
``basetype`` is selected,
computes the pointer to access this element/field assuming ``source`` points
to the start of ``basetype``.
This pointer becomes the new ``source``, the current type the new
-``basetype``, and the next indices is consumed until a scalar type is
+``basetype``, and the next index is consumed until a scalar type is
reached or all indices are consumed.
-All indices must be consumed, and it is illegal to index into a scalar type.
-Meaning the maximum number of indices depends on the depth of the basetype.
-
-Because this instruction performs a logical addressing, all indices are
-assumed to be inbounds. This means it is not possible to access the next
-element in the logical layout by overflowing:
-
-- If the indexed type is a struct with N fields, the index must be an
- immediate/constant value in the range ``[0; N[``.
-- If indexing into an array or vector, the index can be a variable, but
- is assumed to be inbounds with regards to the current basetype logical
layout.
-- If the traversed type is an array or vector of N elements with ``N > 0``,
- the index is assumed to belong to ``[0; N[``.
-- If the traversed type is an array of size ``0``, the array size is assumed
- to be known at runtime, and the instruction assumes the index is always
- inbounds.
-
-In all cases **except** when the accessed type is a 0-sized array, indexing
-out of bounds yields `poison`. When the index value is unknown, optimizations
-can use the type bounds to determine the range of values the index can have.
+All indices must be consumed, and it is illegal to index into a scalar type,
+meaning the maximum number of indices depends on the depth of the basetype.
+
+If the indexed type is a struct with N fields, the index must be an
+integer constant in the range ``[0, N[``.
+
+If the constraints implied by a flag bit are violated, the result is
``poison``.
If the source pointer is poison, the instruction returns poison.
The resulting pointer belongs to the same address space as ``source``.
This instruction does not dereference the pointer.
+Defined flag bits:
+""""""""""""""""""
+
+``inbounds``
+ Bit 0 (``1 << 0``) - specifies that this index is within the bounds of the
type
+ being indexed at that level. In particular, when indexing an array or vector
+ ``[ N x T ]``, implies that the index is in the range ``[0, N[``. As an
exception,
+ if ``N`` is 0, the bound is treated as an unknown, dynamic value, but the
flag
+ still implies that the index is inside that runtime bound.
+ Structure accesses are always ``inbounds`` and must be marked as
+ such. A structured GEP is said to be inbounds if all of its indices are
inbounds.
+
+``nneg``
+ Bit 1 (``1 << 1``) - specifies that the value of this index is non-negative.
+ This is not necessarily implied by ``inbounds``, as an object may have more
+ fields than the maximal signed value for the index type.
----------------
Keenuts wrote:
Thanks for the refined proposal! Trying to gather back context so I might miss
something obvious here:
> ```llvm
> %q = sgep [8 x target("amdgpu.stridemark")], inbounds|nneg, ptr addrspace(9)
> %p, i32 4
> %r = sgep [8 x target("amdgpu.stridemark")], inbounds, ptr addrspace(9) %q,
> i32 %x
> ```
>
> where `inbounds` only implies that `-4 <= %x <= 4`.
My understanding of this is that the pointer `%r` is not a subobject we access
through `%p` anymore, but we in fact access the same initial array right?
If so, this might mean we cannot do SROA anymore:
```
%ptr = sgep [128 x [2 x i32]], ptr %src, i32 3
%use = sgep [2 x i32], ptr %ptr, i32 %n
```
Here, with the current behavior, we know `%n` cannot reach back to any other
index in the 128-elements base array, meaning it is valid to say only one index
is used, and we could maybe simplify the array allocation to only allocate a
single `[2 x i32]`.
I think it's OK to accept having pointers not starting at the base of an
object/allocation, but if you want to drop the "subobject provenance" bit, I'd
like to make sure we can still implement something like SROA (@bogner, this is
important for you)
https://github.com/llvm/llvm-project/pull/200093
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
