[PATCH] D90708: [LangRef] Clarify GEP inbounds wrapping semantics
Nuno Lopes via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Nov 4 01:03:51 PST 2020
nlopes added a comment.
LGTM modulo the two comments. Thanks for writing this down!
================
Comment at: llvm/docs/LangRef.rst:9772
+* The base pointer is an *in bounds* address of an allocated object, which
+ means that it points into or one byte past the end of an allocated object.
+ The only *in bounds* address for a null pointer in the default
----------------
I think the "one byte past" can be misleading. A pointer can point to the end of an object, or as the C++ standard puts it, it may point to a hypothetical next element n if the object has n elements.
http://eel.is/c++draft/basic.compound#3.4
================
Comment at: llvm/docs/LangRef.rst:9782
+ applies to each of the computations element-wise.
+
+As a corollary, the following two properties follow:
----------------
one more case is that offsets must fit (signed-wise) in the address space's size. So a GEP with 64 bits offsets on a 32-bit address space is OK as long as those offsets fit in 32 bits.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D90708/new/
https://reviews.llvm.org/D90708
More information about the llvm-commits
mailing list