davidchisnall wrote: Some optimisers assume that, if they know something about the address, they know something about the bit pattern in memory. That is currently captured as a non-integral property.
The other thing, which might be better captured with intrinsics, is that a ptrtoint instruction does not need to be treated as escaping because inttoptr instructions are not permitted on non-integral pointers (that doesn’t seem to be explicit, but is implied, I think). I do wonder for CHERI if the right thing is to disallow both inttoptr and ptrtoint and upstream our set and get address intrinsics with the same provenance guarantees as the Rust strict provenance model (and our WIP C++ strict provenance rules). That would mean that NI could explicitly disallow both ptrtoint and inttoptr (and the verifiers could check that), optimisers would have more aliasing information from source languages that have sensible provenance models, and we’d have target-agnostic ways of representing the escaping vs non-escaping casts. 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
