[PATCH] D135158: [DataLayout] Introduce DataLayout::getPointerIntegralSize(AS)

David Chisnall via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 5 01:51:59 PDT 2022


theraven added a comment.

> CHERI capabilities aren't non-integral. Converting a capability to an integer gives you the address, discarding the metadata (which is also stable*), which is as well-defined as it is on normal architectures.

Note that this is purely for historical reasons: Non-integral pointers were not available when we started.  I worked with the folks pushing NI pointers to make sure that they'd work with CHERI and the plan was always to move over to NI at some point.

I overloaded the semantics of `ptrtoint` as get-address as a quick hack to make things work but it's definitely not the right thing to do and we spent several years working with other folks with similar requirements to upstream features that would let us move away from this.  The behaviour of CHERI's `ptrtoint` is confusing to optimisers.  I believe that the correct solution (which, I vaguely recall, I wrote in a roadmap doc before I left the CL) is:

1. Make CHERI use NI pointers.
2. Make clang generate get-address intrinsics instead of `ptrtoint`.
3. Help fix any optimisations that try to introduce `ptrtoint` for NI pointers.
4. Make the CHERI back ends reject `PTRTOINT` DAG nodes.

CHERI LLVM IR should only ever have get-address and set-address intrinsics, no `inttoptr` and `ptrtoint` instructions.  This should improve optimisations for things that round-trip addresses through pointers because `ptrtoint` is treated as an escape for alias analysis, whereas get-address is not and set-address is explicitly a provenance-carrying operation that works directly with alias analysis.  This structure is also desirable for Rust's Strict Provenance model, even with non-CHERI targets.

This is also the approach that I've recommended to the embecosm folks working on preparing CHERI LLVM for upstreaming.  It would be great if more people could join those calls.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135158/new/

https://reviews.llvm.org/D135158



More information about the llvm-commits mailing list