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

Ralf via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 29 08:07:19 PDT 2023


RalfJung added inline comments.


================
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:
> > 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.
> This is covered by the 4th bullet point:
> 
> > The successive addition of the current address, interpreted as an unsigned
> > number, and an offset, interpreted as a signed number, does not wrap the
> > unsigned address space and remains *in bounds* of the allocated object.
That's not clear at all IMO. It says "an offset", singular -- so I figured just a single offset is added to the current address, namely the sum that was computed in step 3.

This is why we need  more than English prose in such a spec...


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

https://reviews.llvm.org/D154051



More information about the llvm-commits mailing list