The current LangRef wording for GEP inbounds is not very clear in what it implies in terms of wrapping restrictions for the underlying additions and multiplications. This updates LangRef with my understanding of how this is currently being interpreted in practice.
For example, there's this SCEV comment: https://github.com/llvm/llvm-project/blob/7f34aca083b528db1d880b406f1a1953eeb6aa95/llvm/lib/Analysis/ScalarEvolution.cpp#L5061-L5066
Another indication is the fact that clang emits pointer comparisons using unsigned predicates, so we must be assuming that allocated objects cannot wrap the unsigned address space. (For address space 0 this is automatically given because there may be no allocated object containing the null pointer.)
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. We have at least one important target (x86-64) where this is a given by hardware constraints. But I don't know if we can get away with making that a general limitation. (I don't think it's a good idea to make core GEP semantics target-dependent.)