[clang] [llvm] [IR] Add flags operand to structured.gep (PR #200093)

[Nathan Gauër via cfe-commits]

================
@@ -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