Const-Eval on Opensource internals

Provenance in Eight Bytes: How rustc Packs a Pointer's Identity

Jay Hubbert — Wed, 21 Oct 2026 12:45:00 +0000

TL;DR: A pointer in rustc’s const evaluator needs to say which allocation it points into, whether it is immutable, and whether it is a shared reference. rustc packs all three into one NonZero<u64> using the top two bits as flags — and stores the provenance of the bytes in memory sparsely, as whole-pointer relocations, so ordinary data carries almost no overhead.

The packed provenance

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/pointer.rs:82-116

/// The type of provenance in the compile-time interpreter.
/// This is a packed representation of:
/// - an `AllocId` (non-zero)
/// - an `immutable: bool`
/// - a `shared_ref: bool`
///
/// with the extra invariant that if `immutable` is `true`, then so
/// is `shared_ref`.
#[derive(Copy, Clone, Eq, Hash, Ord, PartialEq, PartialOrd)]
pub struct CtfeProvenance(NonZero<u64>);

impl From<AllocId> for CtfeProvenance {
 fn from(value: AllocId) -> Self {
 let prov = CtfeProvenance(value.0);
 assert!(
 prov.alloc_id() == value,
 "`AllocId` with the highest bits set cannot be used in CTFE"
 );
 prov
 }
}
...
const IMMUTABLE_MASK: u64 = 1 << 63; // the highest bit
const SHARED_REF_MASK: u64 = 1 << 62;
const ALLOC_ID_MASK: u64 = u64::MAX & !IMMUTABLE_MASK & !SHARED_REF_MASK;

impl CtfeProvenance {
 /// Returns the `AllocId` of this provenance.
 #[inline(always)]
 pub fn alloc_id(self) -> AllocId {
 AllocId(NonZero::new(self.0.get() & ALLOC_ID_MASK).unwrap())
 }

Three facts in eight bytes:

the AllocId, which is already a NonZero<u64>;
immutable, in bit 63;
shared_ref, in bit 62.

And the invariant “immutable implies shared_ref” means the pair encodes only four states, not eight — the flags are not independent.

Because it is a NonZero, Option<CtfeProvenance> is niche-optimized to 8 bytes, and the pointer stays small:

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/pointer.rs:224-234

#[derive(Copy, Clone, Eq, PartialEq, TyEncodable, TyDecodable, Hash)]
#[derive(StableHash)]
pub struct Pointer<Prov = CtfeProvenance> {
 pub(super) offset: Size, // kept private to avoid accidental misinterpretation (meaning depends on `Prov` type)
 pub provenance: Prov,
}

static_assert_size!(Pointer, 16);
// `Option<Prov>` pointers are also passed around quite a bit
// (but not stored in permanent machine state).
static_assert_size!(Pointer<Option<CtfeProvenance>>, 16);

Sixteen bytes for a pointer (offset + provenance), whether or not the provenance is optional. That matters because every load and store in the interpreter goes through a Pointer.

The naive design — struct Provenance { alloc: AllocId, immutable: bool, shared: bool } — would be 16 bytes with padding, and Option<Provenance> would be 24. That is a 50% increase in the size of every pointer the interpreter touches.

The sparse provenance map

The provenance of pointers stored in memory is a separate structure:

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/provenance_map.rs:1-42

//! Store the provenance for each byte in the range, with a more efficient
//! representation for the common case where PTR_SIZE consecutive bytes have the same provenance.
...
/// Stores the provenance information of pointers stored in memory.
#[derive(Clone, PartialEq, Eq, Hash, Debug)]
#[derive(StableHash)]
pub struct ProvenanceMap<Prov = CtfeProvenance> {
 /// `Provenance` in this map applies from the given offset for an entire pointer-size worth of
 /// bytes. Two entries in this map are always at least a pointer size apart.
 ptrs: SortedMap<Size, Prov>,
 /// This stores byte-sized provenance fragments.
 bytes: Option<Box<SortedMap<Size, PointerFrag<Prov>>>>,
}

Two levels:

ptrs — the common case. A whole pointer stored at an aligned offset gets one entry, not one per byte. This is exactly the “relocation” model that LLVM’s constant materializer uses, so intern can hand the same list to the backend without translation.
bytes — the rare case of a partially overwritten pointer. It is Option<Box<...>>, so for essentially every allocation it is None: one null pointer.

The alternative — provenance per byte — would need 8 bytes of metadata per 8 bytes of data, doubling the memory of every allocation, plus a hash lookup per byte.

Merging the fragments back

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/provenance_map.rs:151-182

/// Attempt to merge per-byte provenance back into ptr chunks, if the right fragments
/// sit next to each other. Return `false` if that is not possible due to partial pointers.
pub fn merge_bytes(&mut self, cx: &impl HasDataLayout) -> bool {
 let Some(bytes) = self.bytes.as_deref_mut() else {
 return true;
 };
 let ptr_size = cx.data_layout().pointer_size();
 while let Some((offset, first_frag)) = bytes.iter().next() {
 let offset = *offset;
 // Check if this fragment starts a pointer.
 let range = offset..offset + ptr_size;
 let frags = bytes.range(range.clone());
 if frags.len() != ptr_size.bytes_usize() {
 // We can't merge this one, no point in trying to merge the rest.
 return false;
 }
 for (idx, (_offset, frag)) in frags.iter().enumerate() {
 if !(frag.prov == first_frag.prov
 && frag.bytes == first_frag.bytes
 && frag.idx == idx as u8)
 {
 return false;
 }
 }
 // Looks like a pointer! Move it over to the ptr provenance map.
 self.ptrs.insert(offset, first_frag.prov);
 bytes.remove_range(range);
 }
 // We managed to convert everything into whole pointers.
 self.bytes = None;
 true
}

If the byte fragments happen to describe a real pointer (same provenance, contiguous, in order), they are folded back into a single ptrs entry and the byte map is dropped entirely. This is what allows a backend to receive a plain relocation list.

Hashing large allocations

One more place where “big data, small hash” shows up:

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation.rs:228-274

/// This is the maximum size we will hash at a time, when interning an `Allocation` and its
/// `InitMask`. Note, we hash that amount of bytes twice: at the start, and at the end of a buffer.
/// Used when these two structures are large: we only partially hash the larger fields in that
/// situation. See the comment at the top of their respective `Hash` impl for more details.
const MAX_BYTES_TO_HASH: usize = 64;

/// This is the maximum size (in bytes) for which a buffer will be fully hashed, when interning.
/// Otherwise, it will be partially hashed in 2 slices, requiring at least 2 `MAX_BYTES_TO_HASH`
/// bytes.
const MAX_HASHED_BUFFER_LEN: usize = 2 * MAX_BYTES_TO_HASH;
...
impl hash::Hash for Allocation {
 fn hash<H: hash::Hasher>(&self, state: &mut H) {
 ...
 let byte_count = bytes.len();
 if byte_count > MAX_HASHED_BUFFER_LEN {
 // Hash the buffer's length.
 byte_count.hash(state);

 // And its head and tail.
 bytes[..MAX_BYTES_TO_HASH].hash(state);
 bytes[byte_count - MAX_BYTES_TO_HASH..].hash(state);
 } else {
 bytes.hash(state);
 }

The comment above it explains the reasoning:

Const allocations are only hashed for interning. However, they can be large, making the hashing expensive especially since it uses FxHash: it’s better suited to short keys, not potentially big buffers like the actual bytes of allocation.

So for buffers over 128 bytes: hash the length, the first 64 bytes and the last 64 bytes. Collisions are caught by the interner’s equality check anyway, and the length+head+tail triple is highly discriminating in practice. O(size) hashing of every const allocation becomes O(1).

The same trick is applied to the init mask’s blocks.

Where it lives

compiler/rustc_middle/src/mir/interpret/pointer.rs — CtfeProvenance, the masks, Pointer.
compiler/rustc_middle/src/mir/interpret/allocation/provenance_map.rs — the sparse map and merge_bytes.
compiler/rustc_middle/src/mir/interpret/allocation.rs — partial hashing.

Takeaway

Two related lessons here. First: niche packing — AllocId is already a NonZero<u64>, and NonZero has a niche, so the two boolean flags cost nothing. Second: representation follows the common case — provenance is stored per pointer, not per byte, and the per-byte fallback is behind an Option<Box<...>> that is None almost always. Both tricks are about the same thing: the rare case should not cost the common case anything.

The Init Mask Is a Single Boolean Until It Isn't: How rustc Tracks Uninitialised Memory

Jay Hubbert — Wed, 21 Oct 2026 12:40:00 +0000

TL;DR: Rust has to know which bytes of a const are initialised, because reading an uninitialised byte is UB. The naive representation is a bitmap — one bit per byte, so a 1 MiB allocation costs 128 KiB. rustc instead starts with a single boolean and only materialises the bitmap when a partial write happens. A full overwrite materialises it back to a boolean.

The representation

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/init_mask.rs:14-42

type Block = u64;

/// A bitmask where each bit refers to the byte with the same index. If the bit is `true`, the byte
/// is initialized. If it is `false` the byte is uninitialized.
/// The actual bits are only materialized when needed, and we try to keep this data lazy as long as
/// possible. Currently, if all the blocks have the same value, then the mask represents either a
/// fully initialized or fully uninitialized const allocation, so we can only store that single
/// value.
#[derive(Clone, Debug, Eq, PartialEq, Encodable_NoContext, Decodable_NoContext, Hash, StableHash)]
pub struct InitMask {
 blocks: InitMaskBlocks,
 len: Size,
}

#[derive(Clone, Debug, Eq, PartialEq, Encodable_NoContext, Decodable_NoContext, Hash, StableHash)]
enum InitMaskBlocks {
 Lazy {
 /// Whether the lazy init mask is fully initialized or uninitialized.
 state: bool,
 },
 Materialized(InitMaskMaterialized),
}

The doc comment says it plainly: “The actual bits are only materialized when needed.”

A freshly allocated buffer is InitMask::new(size, false) — one byte of state, zero bits of bitmap.

Reading it

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/init_mask.rs:48-65

#[inline]
pub fn is_range_initialized(&self, range: AllocRange) -> Result<(), AllocRange> {
 let end = range.end();
 if end > self.len {
 return Err(AllocRange::from(self.len..end));
 }

 match self.blocks {
 InitMaskBlocks::Lazy { state } => {
 // Lazily allocated blocks represent the full mask, and cover the requested range by
 // definition.
 if state { Ok(()) } else { Err(range) }
 }
 InitMaskBlocks::Materialized(ref blocks) => {
 blocks.is_range_initialized(range.start, end)
 }
 }
}

The lazy case is O(1) and touches no memory beyond the single bool.

Writing it, and the two-way transition

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/init_mask.rs:69-100

/// Sets a specified range to a value. If the range is out-of-bounds, the mask will grow to
/// accommodate it entirely.
pub fn set_range(&mut self, range: AllocRange, new_state: bool) {
 let start = range.start;
 let end = range.end();

 let is_full_overwrite = start == Size::ZERO && end >= self.len;

 // Optimize the cases of a full init/uninit state, while handling growth if needed.
 match self.blocks {
 InitMaskBlocks::Lazy { ref mut state } if is_full_overwrite => {
 // This is fully overwriting the mask, and we'll still have a single initialization
 // state: the blocks can stay lazy.
 *state = new_state;
 self.len = end;
 }
 InitMaskBlocks::Materialized(_) if is_full_overwrite => {
 // This is also fully overwriting materialized blocks with a single initialization
 // state: we'll have no need for these blocks anymore and can make them lazy.
 self.blocks = InitMaskBlocks::Lazy { state: new_state };
 self.len = end;
 }
 InitMaskBlocks::Lazy { state } if state == new_state => {
 // Here we're partially overwriting the mask but the initialization state doesn't
 // change: the blocks can stay lazy.
 if end > self.len {
 self.len = end;
 }
 }
 _ => {
 // Otherwise, we have a partial overwrite that can result in a mix of initialization
 // states, so we'll need materialized blocks.
 let len = self.len;
 let blocks = self.materialize_blocks();

Four cases, and note the second one: a full overwrite of an already materialised mask de-materialises it. So the representation is not a one-way ratchet; a memset-style write over a previously partially-written region returns to the one-byte representation.

The third case is subtle and good: a partial write whose value equals the current uniform state also keeps the mask lazy. Writing zeros into a fully-uninitialised buffer does not make it “partially initialised” — it stays fully uninitialised.

The bit-level search

When the mask is materialised, finding the first bit with a given value uses word-at-a-time tricks:

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/init_mask.rs:365-548

/// Search one block, returning the index of the first bit equal to `is_init`.
fn search_block(
 bits: Block,
 block: usize,
 start_bit: usize,
 is_init: bool,
) -> Option<Size> {
 // Invert bits so we're always looking for the first set bit.
 // ! 0b00111011
 // bits = 0b11000100
 let bits = if is_init { bits } else { !bits };
 // Mask off unused start bits.
 // 0b11000100
 // & 0b11111000
 // bits = 0b11000000
 let bits = bits & (!0 << start_bit);
 // Find set bit, if any.
 // bit = trailing_zeros(0b11000000)
 // bit = 6
 if bits == 0 {
 None
 } else {
 let bit = bits.trailing_zeros();
 Some(InitMaskMaterialized::size_from_bit_index(block, bit))
 }
}

trailing_zeros on a u64 is a single TZCNT instruction, and whole blocks that are uniformly 0 or 1 are skipped entirely.

And the loop is written for codegen:

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/init_mask.rs:493-503

if start_block < end_block_inclusive {
 // This loop is written in a specific way for performance.
 // Notably: `..end_block_inclusive + 1` is used for an inclusive range instead of `..=end_block_inclusive`,
 // and `.zip(start_block + 1..)` is used to track the index instead of `.enumerate().skip().take()`,
 // because both alternatives result in significantly worse codegen.

The proof that it is correct

The fast implementation is checked against a naive reference in debug builds:

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/init_mask.rs:530-547

fn find_bit_slow(
 init_mask: &InitMaskMaterialized,
 start: Size,
 end: Size,
 is_init: bool,
) -> Option<Size> {
 (start..end).find(|&i| init_mask.get(i) == is_init)
}

let result = find_bit_fast(self, start, end, is_init);

debug_assert_eq!(
 result,
 find_bit_slow(self, start, end, is_init),
 "optimized implementation of find_bit is wrong for start={start:?} end={end:?} is_init={is_init} init_mask={self:#?}"
);

Keeping the naive version in the tree as an executable specification is a lovely practice: it costs nothing in release builds and catches any divergence immediately.

The run-length encoding for repeated copies

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/init_mask.rs:646-724

/// Run-length encoding of the uninit mask.
/// Used to copy parts of a mask multiple times to another allocation.
pub struct InitCopy {
 /// Whether the first range is initialized.
 initial: bool,
 /// The lengths of ranges that are run-length encoded.
 /// The initialization state of the ranges alternate starting with `initial`.
 ranges: smallvec::SmallVec<[u64; 1]>,
}

The comment explains the motivation:

Since we are copying size bytes from src to dest + i * size (for i in 0..repeat), a naive initialization mask copying algorithm would repeatedly have to read the initialization mask from the source and write it to the destination. Even if we optimized the memory accesses, we’d be doing all of this repeat times. Therefore we precompute a compressed version of the initialization mask of the source value and then write it back repeat times without computing any more information from the source.

So [x; 1000] does O(1) work per repeat instead of O(repeat × size). And the uniform case short-circuits entirely:

 rust
 
 
// compiler/rustc_middle/src/mir/interpret/allocation/init_mask.rs:699

pub fn apply_copy(&mut self, defined: InitCopy, range: AllocRange, repeat: u64) {
 // An optimization where we can just overwrite an entire range of initialization bits if
 // they are going to be uniformly `1` or `0`. ...
 if defined.ranges.len() <= 1 {
 let start = range.start;
 let end = range.start + range.size * repeat; // `Size` operations
 self.set_range(AllocRange::from(start..end), defined.initial);
 return;
 }

Where it lives

compiler/rustc_middle/src/mir/interpret/allocation/init_mask.rs — the whole file: InitMask, InitMaskBlocks, find_bit, InitCopy.
compiler/rustc_middle/src/mir/interpret/allocation/provenance_map.rs — the sibling trick for provenance (a lazily allocated byte map).

Takeaway

This is the “one bit can carry a lot of information” pattern: most allocations are either fully initialised or fully uninitialised, and the representation should reflect the common case, not the worst case. The transition is bidirectional, so the mask degrades and recovers gracefully instead of monotonically growing.

One Interpreter, Two Machines: How rustc's Const Eval Powers Miri Too

Jay Hubbert — Wed, 21 Oct 2026 12:35:00 +0000

TL;DR: rustc’s constant evaluator is not “the const evaluator” with hooks for Miri bolted on. It is a generic interpreter written against a Machine trait with eight associated types and 57 methods. CTFE and Miri are two instantiations. That is why Miri gets UBSan-grade checking for free, and why the core interpreter has no idea which one it is serving.

The trait

 rust
 
 
// compiler/rustc_const_eval/src/interpret/machine.rs:113-163

/// Methods of this trait signifies a point where CTFE evaluation would fail
/// and some use case dependent behaviour can instead be applied.
pub trait Machine<'tcx>: Sized {
 /// Additional memory kinds a machine wishes to distinguish from the builtin ones
 type MemoryKind: Debug + std::fmt::Display + MayLeak + Eq + 'static;

 /// Pointers are "tagged" with provenance information; typically the `AllocId` they belong to.
 type Provenance: Provenance + Eq + Hash + 'static;

 /// When getting the AllocId of a pointer, some extra data is also obtained from the provenance
 /// that is passed to memory access hooks so they can do things with it.
 type ProvenanceExtra: Copy + 'static;

 /// Machines can define extra (non-instance) things that represent values of function pointers.
 /// For example, Miri uses this to return a function pointer from `dlsym`
 /// that can later be called to execute the right thing.
 type ExtraFnVal: Debug + Copy;

 /// Extra data stored in every call frame.
 type FrameExtra;

 /// Extra data stored in every allocation.
 type AllocExtra: Debug + Clone + 'tcx;

 /// Type for the bytes of the allocation.
 type Bytes: AllocBytes + 'static;

 /// Memory's allocation map
 type MemoryMap: AllocMap<
 AllocId,
 (
 MemoryKind<Self::MemoryKind>,
 Allocation<Self::Provenance, Self::AllocExtra, Self::Bytes>,
 ),
 > + Default
 + Clone;

Eight associated types covering: how memory kinds are distinguished, how provenance is represented, what extra data a function pointer can carry, what goes in a call frame, what goes in an allocation, how bytes are stored, and how the allocation map works.

The design decision that matters: the trait is pure, with associated types rather than &mut dyn objects. Every hook is a static call after monomorphization, so the interpreter’s inner loop — which runs millions of steps during a const evaluation — has no virtual dispatch.

The shared compile-time instantiation

 rust
 
 
// compiler/rustc_const_eval/src/interpret/machine.rs:692-712

/// A lot of the flexibility above is just needed for `Miri`, but all "compile-time" machines
/// (CTFE and ConstProp) use the same instance. Here, we share that code.
pub macro compile_time_machine(<$tcx: lifetime>) {
 type Provenance = CtfeProvenance;
 type ProvenanceExtra = bool; // the "immutable" flag

 type ExtraFnVal = !;

 type MemoryKind = $crate::const_eval::MemoryKind;
 type MemoryMap =
 rustc_data_structures::fx::FxIndexMap<AllocId, (MemoryKind<Self::MemoryKind>, Allocation)>;
 const GLOBAL_KIND: Option<Self::MemoryKind> = None; // no copying of globals from `tcx` to machine memory

 type AllocExtra = ();
 type FrameExtra = ();
 type Bytes = Box<[u8]>;

Three details worth stopping on:

type ExtraFnVal = ! — the empty type. Miri can return a function pointer from dlsym; CTFE cannot. By making the type uninhabited, the CTFE instantiation of call_extra_fn becomes match fn_val {} — the capability is statically impossible, at zero runtime cost.
GLOBAL_KIND = None — globals are never copied out of tcx into the interpreter’s memory. A static that is only read costs nothing; a naive design would clone the whole allocation on every access.
type Bytes = Box<[u8]> — an exactly-sized, contiguous byte store. Miri uses a Vec<u8> plus separate provenance tracking; CTFE does not need per-byte provenance for ordinary data.

The lazy operand model

 rust
 
 
// compiler/rustc_const_eval/src/interpret/operand.rs:25-41

/// An `Immediate` represents a single immediate self-contained Rust value.
///
/// For optimization of a few very common cases, there is also a representation for a pair of
/// primitive values (`ScalarPair`). It allows Miri to avoid making allocations for checked binary
/// operations and wide pointers. This idea was taken from rustc's codegen.
/// In particular, thanks to `ScalarPair`, arithmetic operations and casts can be entirely
/// defined on `Immediate`, and do not have to work with a `Place`.
#[derive(Copy, Clone, Debug)]
pub enum Immediate<Prov: Provenance = CtfeProvenance> {
 /// A single scalar value (must have *initialized* `Scalar` ABI).
 Scalar(Scalar<Prov>),
 /// A pair of two scalar value (must have `ScalarPair` ABI where both fields are
 /// `Scalar::Initialized`).
 ScalarPair(Scalar<Prov>, Scalar<Prov>),
 /// A value of fully uninitialized memory. Can have arbitrary size and layout, but must be sized.
 Uninit,
}

and:

 rust
 
 
// compiler/rustc_const_eval/src/interpret/operand.rs:476-489

/// An `Operand` is the result of computing a `mir::Operand`. It can be immediate,
/// or still in memory. The latter is an optimization, to delay reading that chunk of
/// memory and to avoid having to store arbitrary-sized data here.
#[derive(Copy, Clone, Debug)]
pub(super) enum Operand<Prov: Provenance = CtfeProvenance> {
 Immediate(Immediate<Prov>),
 Indirect(MemPlace<Prov>),
}

Operand::Indirect(MemPlace) means the value is still in memory. So an operand that is never read — the destination of a Drop, an argument that is overwritten before use — costs zero memory traffic.

And ScalarPair means a wide pointer (&[T], &dyn Trait) or a two-field tuple lives in registers, with no allocation at all.

Projecting out of a ScalarPair is register shuffling

 rust
 
 
// compiler/rustc_const_eval/src/interpret/operand.rs:409-431

// This makes several assumptions about what layouts we will encounter; we match what
// codegen does as good as we can (see `extract_field` in `rustc_codegen_ssa/src/mir/operand.rs`).
let inner_val: Immediate<_> = match (**self, self.layout.backend_repr) {
 // If the entire value is uninit, then so is the field (can happen in ConstProp).
 (Immediate::Uninit, _) => Immediate::Uninit,
 // If the field is uninhabited, we can forget the data (can happen in ConstProp).
 // `enum S { A(!), B, C }` is an example of an enum with Scalar layout that
 // has an uninhabited variant, which means this case is possible.
 _ if layout.is_uninhabited() => Immediate::Uninit,
 // the field contains no information, can be left uninit
 // (Scalar/ScalarPair can contain even aligned ZST, not just 1-ZST)
 _ if layout.is_zst() => Immediate::Uninit,
 ...
 // extract fields from types with `ScalarPair` ABI
 (
 Immediate::ScalarPair(a_val, b_val),
 BackendRepr::ScalarPair { a: _, b: _, b_offset },
 ) => Immediate::from(if offset.bytes() == 0 {
 a_val
 } else {
 assert_eq!(offset, b_offset);
 b_val
 }),

Field 0 or field 1 out of a ScalarPair is a branch on the offset, not a memory load. ZST and uninhabited fields collapse to Uninit without ever touching bytes.

A micro-optimisation kept on purpose

 rust
 
 
// compiler/rustc_const_eval/src/interpret/operand.rs:803-807

let mut op = self.local_to_op(mir_place.local, layout)?;
// Using `try_fold` turned out to be bad for performance, hence the loop.
for elem in mir_place.projection.iter() {
 op = self.project(&op, elem)?
}

The comment preserves a decision that a future refactoring would undoubtedly “clean up”: the iterator-combinator version measured slower than the plain loop.

Where it lives

compiler/rustc_const_eval/src/interpret/machine.rs — the Machine trait and compile_time_machine!.
compiler/rustc_const_eval/src/const_eval/machine.rs — the CTFE instantiation.
compiler/rustc_const_eval/src/interpret/operand.rs — Immediate, Operand, ScalarPair.
compiler/rustc_miri/src/const_eval/machine.rs — the Miri instantiation.

Takeaway

Genericity is usually traded against concreteness: the more hooks you put behind a trait, the slower the hot path. rustc avoided that trade by making the trait pure (associated types, not trait objects), so the interpreter’s inner loop stays monomorphised and inlinable. The result is that Miri’s provenance tracking and CTFE’s cheapness coexist in one implementation — and Miri gets its strict aliasing model for free, because the machinery was always there.