oic, llvm.org/docs/GetElemen helped me make more sense of it: because an inbounds gep isn't permitted to overflow, you can do more clever games with the ordering of element pointers from inbounds geps
Conversation
Replying to
it's also one of those things where like, basically *every* pointer offset llvm ever messes with is `inbounds` so random shit might just require it because it makes things easier and no one cares about non-inbounds codegen
1
1
Replying to
it's *unlikely* but not *impossible* to have a 2^31+2-byte alloc on a 32-bit architecture, and i'm computing the end pointer ahead of time
2
2
Replying to
oh yeah i, yep -- i am now remembering spending way too much time worrying about overflowing pointer shit in the stdlib for exactly 32-bit and shit like PAE
1
1
but yeah llvm *extremely* pervasively assumes pointer offsets fit into an isize without overflow so it's generally "safe" to assume no one ever creates such an allocation because it would break so extremely bad -- certainly the rust stdlib avoids ever generating such an alloc
1
3
I had to add wording to Rust's language specification forbidding objects larger than isize::MAX (PTRDIFF_MAX in C) because anything larger is incredibly broken in either LLVM or GCC. It's the only realistic way to enforce safety.
See gcc.gnu.org/bugzilla/show_ for a GCC example.
1
1
Also, too hard to avoid doing x-y everywhere which would be undefined even with a looser interpretation of the standard not assuming this is handled by the runtime.
Runtime must not put allocation at 0 or size::MAX and needs to enforce isize::MAX size. GCC/LLVM both assume this.
This isn't an issue on most platforms for either pure 32-bit or 64-bit architectures. It's a real world issue for 32-bit processes on 64-bit. musl, Bionic, jemalloc, etc. prevent you creating an object larger than PTRDIFF_MAX. glibc does not, so it's broken with GCC and LLVM.
1