You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are there plans to make the ptr_mask (and therefore ptr::mask) usable from const contexts?
This currently depends on making ptr::map_addr and ptr::with_addrconst, which would need to be discussed in the context of the strict provenance project.
These functions cannot in general be made const-compatible, since their behavior depends on the exact bits of a pointer value which are not known at compile-time. with_addr will never be const. (More specifically, subtracting two pointers will never be possible at const-time, and with_addr depends on that ability.)
Certain tricks could be played for the specific case where the original allocation was sufficiently aligned to make the lowest bits of the pointers statically predictable. That would need new specialized intrinsics though, it cannot be implemented via with_addr.
Don't we also need an operation that corresponds to ptr.map_addr(|a| a | mask) to make this sufficient for tagged pointers? But somehow LLVM seems to only support &, not |, on pointers?
(Maybe LLVM should just support what we call addr and with_addr, then it wouldn't need a bunch of new pointer versions for each integer operation...)
LLVM currently doesn't have something like addr because the necessary analysis infrastructure to capitalize on it isn't in place (yet). LLVM currently combines address capture and provenance escape into one concept, and the addr vs ptrtoint distinction only really becomes relevant once you separate them. This is something I have on my long term TODO list, but never get around to...
Activity
hsanzg commentedon Jul 21, 2024
Are there plans to make the
ptr_mask(and thereforeptr::mask) usable fromconstcontexts?This currently depends on making
ptr::map_addrandptr::with_addrconst, which would need to be discussed in the context of the strict provenance project.RalfJung commentedon Jul 21, 2024
These functions cannot in general be made const-compatible, since their behavior depends on the exact bits of a pointer value which are not known at compile-time.
with_addrwill never beconst. (More specifically, subtracting two pointers will never be possible at const-time, andwith_addrdepends on that ability.)Certain tricks could be played for the specific case where the original allocation was sufficiently aligned to make the lowest bits of the pointers statically predictable. That would need new specialized intrinsics though, it cannot be implemented via
with_addr.RalfJung commentedon Sep 14, 2024
Don't we also need an operation that corresponds to
ptr.map_addr(|a| a | mask)to make this sufficient for tagged pointers? But somehow LLVM seems to only support&, not|, on pointers?(Maybe LLVM should just support what we call
addrandwith_addr, then it wouldn't need a bunch of new pointer versions for each integer operation...)Cc @nikic
nikic commentedon Sep 14, 2024
LLVM currently doesn't have something like
addrbecause the necessary analysis infrastructure to capitalize on it isn't in place (yet). LLVM currently combines address capture and provenance escape into one concept, and the addr vs ptrtoint distinction only really becomes relevant once you separate them. This is something I have on my long term TODO list, but never get around to...RalfJung commentedon Sep 14, 2024