[PATCH] D90708: [LangRef] Clarify GEP inbounds wrapping semantics

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D90708#2375628 <https://reviews.llvm.org/D90708#2375628>, @nhaehnle wrote:

> This makes sense to me.
>
>> However, I do wonder if we could get away with saying that no allocated object may wrap the signed address space, in which case inbounds would just map cleanly to nsw, which would both allow more optimization and be easier to reason about.
>
> Unfortunately, that wouldn't work for us. We have 32-bit address spaces that are treated as the unsigned range [0, 0xffffffff], and there's no limitation as to where objects can appear in that range.

Yeah, doesn't look like we can require this in the general case. I also checked that malloc does indeed return allocations that cross the sign boundary for `-m32` binaries, using the following code:

  #include <stdio.h>
  #include <stdlib.h>
  #define BLOCK_SIZE (128 * 1024 * 1024)
  int main() {
      while (1) {
          char *ptr = malloc(BLOCK_SIZE);
          if (!ptr) {
              printf("OOM!\n");
              return 0;
          }
          printf("%p - %p\n", ptr, ptr + BLOCK_SIZE);
      }
  }

So if we wanted to make use of the x86-64 address space layout, we'd have to do that based on a datalayout property or so, and that's out of scope of this change (and likely generally not worthwhile).



================
Comment at: llvm/docs/LangRef.rst:9785-9786
+   unsigned address space and remains *in bounds* of the allocated object.
+   As a corollary, if the added offset is non-negative, the addition does not
+   wrap in an unsigned sense (``nuw``).
+*  In cases where the base is a vector of pointers, the ``inbounds`` keyword
----------------
nhaehnle wrote:
> As a second corollary, the addition wraps in an unsigned sense if and only if the added offset is negative?
I agree that this statement is true, but is it also useful for something? Not sure in what way optimizations would make use of the fact that the calculation always wraps.


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

https://reviews.llvm.org/D90708