[PATCH] D154051: [LangRef] Always allow getelementptr inbounds with zero offset

[Ralf via Phabricator via llvm-commits]

RalfJung added inline comments.


================
Comment at: llvm/docs/LangRef.rst:10931
 *  The base pointer has an *in bounds* address of an allocated object, which
-   means that it points into an allocated object, or to its end. The only
-   *in bounds* address for a null pointer in the default address-space is the
-   null pointer itself.
+   means that it points into an allocated object, or to its end.
 *  If the type of an index is larger than the pointer index type, the
----------------
nikic wrote:
> RalfJung wrote:
> > This might be a good opportunity to clarify that the allocated objects does not have to be live.
> That seems orthogonal to the change here, so I'd rather not include it. Properly specifying the notion of a dead allocated object seems pretty tricky.
Even without properly specifying it, just mentioning this seems useful -- when reading the docs I never even considered that a dead pointer might be considered inbounds of anything.

But yeah it is orthogonal. I might make a PR for that (probably only once I can do that on github so that it's not so painful^^).


================
Comment at: llvm/docs/LangRef.rst:10946
 
+Note that ``getelementptr`` with all-zero indices is always considered to be
+``inbounds``, even if the base pointer does not point to an allocated object.
----------------
nikic wrote:
> RalfJung wrote:
> > Are negative indices supported? If yes, is it possible that multiple indices "cancel" to leave the total effective offset as 0 despite there being non-0 indices?
> Multiple indices are not allowed to cancel. The "any non-zero" and "all-zero" wordings here are intentional. This is consistent with usual inbounds semantics, which also do not allow "temporarily" going out of bounds.
> 
> (We do have optimizations that depend on this.)
Oh, that is very surprising and not clear from the docs. The docs talk about adding the offsets to each other without the base address (3rd bullet) which strongly indicates that first offsets are added up, and then the final accumulated offset is added to the base, and then the result has to be inbounds. If that's not the semantics I think it needs clarification.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154051/new/

https://reviews.llvm.org/D154051