hi rust twitter: ptr:add (doc.rust-lang.org/std/primitive.) points to wrapping_add (doc.rust-lang.org/std/primitive.) as an alternative if safety requirements are difficult to uphold, but says that wrapping_add disallows some "aggressive compiler optimizations"
anyone know what those are?
Conversation
Replying to
It has a list of the guarantees provided to the compiler by ptr::add at doc.rust-lang.org/std/primitive..
It maps to an LLVM inbounds GEP rather than GEP. There's documentation on this at llvm.org/docs/LangRef.h. Guarantees result will be within the bounds of the object without wrapping.
1
2
It can't cheat by wrapping all the around and back into the same object. It's a bit silly that the safe one is called wrapping_add because allowing wrapping is only one of the things it allows.
Note that ptr::wrapping_add is safe and ptr::add is unsafe due to the UB.
1
1
It's UB to deference a pointer outside the bounds of the object it was derived from regardless of which one you use. The purpose of ptr::add is that it's also undefined to create the pointer outside bounds of the object which enables optimizations even if load isn't right there.
1
Replying to
i need you to realize you linked me at the exact same part of rust docs that i, myself, linked. i was not asking why one is safe and the other is not, i was asking what optimization differences there are
2
llvm.org/docs/GetElemen is informative in a subtle way: because an inbounds gep cannot overflow, the compiler can make assumptions about ordering of pointers, among other things
1
Replying to
Main guarantees is that it's in-bound. ptr::wrapping_add method is poorly named. The main difference is that it permits the result to not be within the bounds of the object. Disallowing wrapping as part of inbounds is a bonus thing.
1
So, among many other things, it's guaranteed to not be a null pointer and null checks can be eliminated. A negative offset will go backwards within the object, a positive offset will go forwards within the object (up to one byte past the end) and a zero offset will stay the same.
Replying to
"a `negative offset` will go backwards within the object" is not necessarily true, and the entire reason i'm looking closely at these functions
2
if you have a 2^31+1 byte alloc in a 2^32-byte address space, 0x80000001 may be a valid offset that does not go backwards
2
1
Show replies
Among other things, inbounds GEP is a guarantee that the input is not null and the output is not null. A non-inbounds GEP can have a null input and/or output. There is no such thing as a pointer within the bounds of null. This matters a lot for Rust's slice iterators.