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 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
