Values

A VReg is a dense zero-based value handle local to one WasmIRFn. Its type, definition site, and diagnostic origin live in parallel tables indexed by the same number.

Registers are allocated in this order:

1. WebAssembly function parameters;
2. block parameters in block declaration order;
3. instruction results.

Each register is defined exactly once and may have any number of uses, including zero before dead-code elimination.

Natural types

Atoll values map to WebAssembly carriers as follows:

Reference-shaped composites include strings, tuples, arrays, options, function values, pointers, and named aggregates when their selected ABI is indirect. An I32 alone does not say which semantic value it represents; that decision belongs to MIR and is already reflected in the chosen operations.

Wide integers deserve care. Frame storage can reserve 16 bytes and explicitly sign-fill or zero-fill the high half. Wide arithmetic operations can expose low/high lanes. Passes must follow the instruction’s declared lane contract rather than assuming every 128-bit semantic value is permanently one I64.

Definition sites

DefSite records one of:

• function parameter index;
• block and block-parameter index;
• block and instruction index;
• a reserved terminator-result form.

The table lets the verifier compute dominance without scanning for an accidental matching destination. When an optimization inserts or moves a definition, it must rebuild the affected definition entries.

VRegOrigin is diagnostic metadata:

• a value derived from a MIR local;
• a WebAssembly parameter;
• a lowering temporary;
• the cached absolute frame address.

Origin does not change value semantics and must not be used as a substitute for the definition table.

Constants

Constants carry exact WebAssembly-shaped bits:

• signed containers for I32 and I64;
• raw IEEE bits for F32 and F64;
• sixteen bytes for V128.

Using bits avoids host-language floating-point canonicalization during encoding. NaN payloads and signed zero remain whatever the selected lowering requires.

Conversions

Every non-storage width or kind change is an explicit Convert with a concrete WebAssembly conversion operator. Arithmetic operations do not silently widen or narrow operands to make their types agree.

Sub-word storage is the deliberate exception:

• one- and two-byte loads choose signed or unsigned extension into I32;
• narrow stores truncate using the selected WebAssembly store width;
• a 16-byte integer store writes its low I64 and fills the high half by sign or zero extension;
• a 16-byte scalar load exposes the selected low-lane behavior unless a dedicated wide operation requests both lanes.

The signedness bit is selected before WasmIR encoding. The encoder may use it to pick an opcode; it may not derive it from an Atoll type.

Memory references

FrameSlot is a distinct wrapper over the finalized MIR slot identity. Frame-slot instructions resolve its byte offset and width through the shared read-only layout.

Flex instructions explicitly name:

• the base register;
• constant byte offset;
• load or store width;
• signedness through the selected load variant.

Frame and flex accesses occupy separate alias domains for optimization. Calls and barriers can conservatively clobber both.

When relocation-safe arena growth is enabled, a host call may republish the arena base. A cached absolute base cannot survive that clobber; frame addressing reloads the authoritative global as required.