[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)

[Alexander Richardson via llvm-branch-commits]

arichardson wrote:

> I think this change would benefit from an RFC on discourse, for wider visibility.
> 
> Something that's not super clear to me is how to reconcile the statements about pointer/integer casts and in-memory type punning. I'd expect that ptrtoint returns an i128 value and if you cast back that value to a pointer, you preserve capabilities. If you truncate the i128 value to i64 and then cast it back, then you obviously don't -- but LLVM should already know that truncation is not a value preserving operation :) Or does ptrtoint actually directly return an i64 value? If it does, then I think you must have additional changes for that, because I don't think that LLVM supports that directly. And if you do, then that may be sufficient?

That is a good suggestion - I will post a RFC soon.

The CHERI downstream ensures that ptrtoint for capabilities only returns the address part of the capability (i.e. i32 for 64-bit capabilities and i64 for 128-bit ones). We added additional helpers to query that width which I attempted to cleanup+upsteream in https://reviews.llvm.org/D135158 and https://reviews.llvm.org/D99660.

Storing via memory preserves capabilities (as long as the load+store are correctly sized and aligned - there is one additional out-of-band bit that is only preserved for capability-typed loads+stores), but casting via same-size integers does not. This also means that the C (u)intptr_t is lowered to `ptr addrspace(200)` instead of `i128` in IR to preserve capability data.

https://github.com/llvm/llvm-project/pull/105735