Skip to content

Commit 1c567a5

Browse files
authored
getelementptr inbounds clarifications (#65478)
- For a long time I assumed that `inbounds` means "in-bounds of a *live* allocation". @nikic told me that is not correct. I think this definitely needs clarification in the docs. - The point about successively adding the offsets to the current address confused be because it talked about the successive addition of "an" offset -- which one? My interpretation was, the total accumulated offset computed in the previous step. But @nikic told me that's not correct, adding each offset individually has to stay in-bounds for each step. I hope by saying "each offset" this becomes more clear; I then also change the previous bullet to use the same terminology.
1 parent 46f3ade commit 1c567a5

File tree

1 file changed

+5
-3
lines changed

1 file changed

+5
-3
lines changed

llvm/docs/LangRef.rst

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -10955,15 +10955,17 @@ If the ``inbounds`` keyword is present, the result value of a
1095510955
:ref:`poison value <poisonvalues>` if one of the following rules is violated:
1095610956

1095710957
* The base pointer has an *in bounds* address of an allocated object, which
10958-
means that it points into an allocated object, or to its end.
10958+
means that it points into an allocated object, or to its end. Note that the
10959+
object does not have to be live anymore; being in-bounds of a deallocated
10960+
object is sufficient.
1095910961
* If the type of an index is larger than the pointer index type, the
1096010962
truncation to the pointer index type preserves the signed value.
1096110963
* The multiplication of an index by the type size does not wrap the pointer
1096210964
index type in a signed sense (``nsw``).
10963-
* The successive addition of offsets (without adding the base address) does
10965+
* The successive addition of each offset (without adding the base address) does
1096410966
not wrap the pointer index type in a signed sense (``nsw``).
1096510967
* The successive addition of the current address, interpreted as an unsigned
10966-
number, and an offset, interpreted as a signed number, does not wrap the
10968+
number, and each offset, interpreted as a signed number, does not wrap the
1096710969
unsigned address space and remains *in bounds* of the allocated object.
1096810970
As a corollary, if the added offset is non-negative, the addition does not
1096910971
wrap in an unsigned sense (``nuw``).

0 commit comments

Comments
 (0)