Capturing Flat ABI representations for Interface Types · wasmtime

As I am building RR into Wasmtime, I recognize the need to allow access to the exact flat ABI representation.Each flat slot is a ValRaw of 128 bytes, and understanding the bytes of significance to record will allow compressions on trace sizes. Right now, it doesn't seem like this ABI is captured anywhere (correct me if I'm wrong). The canonical ABI options now only capture the flat count:

pub struct CanonicalAbiInfo {
    /// The byte-size of this type in a 32-bit memory.
    pub size32: u32,
    /// The byte-alignment of this type in a 32-bit memory.
    pub align32: u32,
    /// The byte-size of this type in a 64-bit memory.
    pub size64: u32,
    /// The byte-alignment of this type in a 64-bit memory.
    pub align64: u32,
    /// The number of types it takes to represents this type in the "flat"
    /// representation of the canonical abi where everything is passed as
    /// immediate arguments or results.
    ///
    /// If this is `None` then this type is not representable in the flat ABI
    /// because it is too large.
    pub flat_count: Option<u8>,
}

My initial impression is we capture this ABI information in the above struct, with something like this, that we can build up with the types:

pub struct FlatAbiInfo {
    count: u8,
    /// A `count` sized array that represents the number of bytes used within each flat slot
    bytes: Vec<u8>
}

pub struct CanonicalAbiInfo {
    /// The byte-size of this type in a 32-bit memory.
    pub size32: u32,
    /// The byte-alignment of this type in a 32-bit memory.
    pub align32: u32,
    /// The byte-size of this type in a 64-bit memory.
    pub size64: u32,
    /// The byte-alignment of this type in a 64-bit memory.
    pub align64: u32,
    /// The flat ABI representation when everything is passed as
    /// immediate arguments or results.
    ///
    /// If this is `None` then this type is not representable in the flat ABI
    /// because it is too large.
    pub flat: Option<FlatAbiInfo>,
}

In fact, we should use the above flat ABI representation to streamline linear_lower_to_flat implementations for all the types as well. It looks like right now this is fully ad-hoc -- to understand the flat ABI completely, I need to look into the detailed implementations of each type.

What do folks think of this? @Alex Crichton might have some more detailed thoughts

Stream: wasmtime

Topic: Capturing Flat ABI representations for Interface Types

Arjun Ramesh (Oct 04 2025 at 23:17):