Section 06: Struct & Tuple Layout Optimization

Context: The spec (Annex E — System Considerations) explicitly permits struct field reordering: “Struct field order in memory may differ from declaration order.” This is a non-guarantee. Rust’s repr(Rust) does exactly this — it reorders fields by alignment to minimize padding. Ori should do the same.

Reference implementations:

Rust compiler/rustc_abi/src/layout.rs: Fields sorted by descending alignment, then by descending size
Zig src/Type.zig: ABI-optimal layout with explicit alignment control
C/C++: No reordering (declaration order = memory order) — this is why #pragma pack exists

Depends on: §04, §05 (need to know narrowed field sizes before computing layout).

Codegen consumers that use field indices (ALL must be remapped after §06):

ArcIrEmitter::emit_project() — extract_value(val, field, ...) and struct_gep(ty, val, field, ...)
ArcIrEmitter::emit_construct() — build_struct(llvm_ty, &narrowed_args, ...) (args ordered by declaration)
ArcIrEmitter::emit_instr() → ArcInstr::Set — struct_gep(llvm_ty, base_val, *field, ...)
compile_for_each_field() in derive_codegen/bodies.rs — extract_value(val, i as u32, ...) where i is declaration-order enumeration
compile_format_fields() in derive_codegen/bodies.rs — same pattern as above
compile_clone_fields() in derive_codegen/bodies.rs — same pattern as above
compile_default_construct() in derive_codegen/bodies.rs — builds struct with build_struct() in declaration order
DropFunctionGenerator in arc_emitter/drop_gen.rs — iterates fields for drop emission
field_scan/mod.rs — ArcInstr::Project { field, .. } used for field usage tracking (read-only analysis; field values opaque to remapping — does NOT need remapping)
sext_narrowed_field() / trunc_for_narrowed_struct() in narrowing_codegen.rs — use field index to look up narrowed width from StructRepr.fields

Non-affected consumers (no remapping needed):

Closure environment codegen (closures.rs, closure_wrappers.rs) — closure environments are not user structs; they have compiler-controlled layout and are not subject to §06 reordering.
Enum variant payload codegen (drop_enum.rs, emit_variant_via_*) — enum payloads use Vec<MachineRepr> (no FieldRepr), and §07 handles enum layout separately.

06.0 Prerequisites: layout module split + codegen field remapping

Current state:

compiler/ori_repr/src/layout.rs is a flat file (not a directory). It contains is_trivial_repr(), field_size(), field_align(), repr_size(), repr_align(), round_up(), compute_field_layout(), compute_payload_layout(), and TupleRepr::to_machine_repr().
MachineRepr has no .size() or .alignment() methods — size/alignment are computed via the free functions field_size(&repr) / field_align(&repr) (for aggregate fields) and repr_size(&repr) / repr_align(&repr) (for standalone values) in layout.rs, all pub(crate).
FieldRepr has fields name: Name, original_index: u32, offset: u32, repr: MachineRepr — there is no type_idx field. The narrowed representation is stored directly in FieldRepr.repr by §04/§05 narrowing passes.
FieldInfo does not exist anywhere in the codebase. The layout algorithm operates on FieldRepr directly.
canonical_struct() in canonical/type_repr.rs already populates FieldRepr with offset: 0 and a comment “Set by §06 layout”. The layout is computed by compute_field_layout() for the struct’s size and align, but individual field offsets are left at 0.
The pipeline stub compute_struct_layouts() already exists in pipeline.rs:469 as an empty function.

Critical codegen concern — field index remapping:

The ARC IR uses ArcInstr::Project { field: u32 } where field is the declaration-order index.
Codegen in arc_emitter/instr_dispatch.rs passes this field directly to struct_gep() as the LLVM struct field index.
After §06 reorders StructRepr.fields (changing the memory order), the LLVM struct type has fields in a different order than the ARC IR expects.
§06 must provide a original_to_memory index mapping so codegen can translate ArcInstr::Project { field: 3 } (declaration index 3) → struct_gep(memory_index) (the reordered position).
The same remapping is needed for ArcInstr::Construct (struct construction) and ArcInstr::Set (field mutation).
try_lower_narrowed_aggregate() in layout_resolver.rs iterates StructRepr.fields in order — after reordering, this produces the LLVM struct type in memory order (correct), but codegen must use the remapped index for GEP access.

Prerequisite steps:

Convert layout.rs to a module directory: (2026-03-29)
- mkdir compiler/ori_repr/src/layout/
- Move compiler/ori_repr/src/layout.rs → compiler/ori_repr/src/layout/mod.rs (existing 177-line file, well under limit)
- Create compiler/ori_repr/src/layout/struct_layout.rs — new: field reordering algorithm + ABI-stable layout functions (§06.1 + §06.3)
- Create compiler/ori_repr/src/layout/tuple_layout.rs — new: tuple layout (§06.4)
- Create compiler/ori_repr/src/layout/tests.rs — new: unit tests for layout algorithms; add #[cfg(test)] mod tests; to mod.rs
- mod layout; in lib.rs auto-discovers the directory module — no change needed
- Add pub(crate) use struct_layout::optimize_struct_layout; and pub(crate) use tuple_layout::optimize_tuple_layout; re-exports in layout/mod.rs

Add StructRepr helper methods for index remapping: (2026-03-29)

impl StructRepr {
    /// Find the field with the given original (declaration-order) index.
    ///
    /// Returns `None` if no field has that original index — a bug.
    pub fn field_by_original(&self, original_index: u32) -> Option<&FieldRepr> {
        self.fields.iter().find(|f| f.original_index == original_index)
    }

    /// Get the memory-order index for a given declaration-order index.
    ///
    /// After §06 reordering, `fields[memory_index].original_index == original_index`.
    /// Before §06 (or for `#repr("c")`), memory order == declaration order.
    pub fn memory_index(&self, original_index: u32) -> Option<usize> {
        self.fields.iter().position(|f| f.original_index == original_index)
    }
}

Wire codegen field-index remapping into ArcIrEmitter: (2026-03-29)
- remap_struct_field() helper on ArcIrEmitter — Tag::Struct/Tuple guard, ReprPlan lookup, memory_index translation.
- reorder_args_to_memory_order() helper for Construct — builds memory-order args from StructRepr.fields.
- emit_project(): extract_value(val, mem_field) and struct_gep(ty, val, mem_field).
- emit_instr() → Set: struct_gep(llvm_ty, base_val, mem_field).
- emit_construct(): args reordered before trunc_for_narrowed_struct() and build_struct().
- Fallback to original index when no ReprPlan entry (backwards-compatible).
Wire codegen field-index remapping into derive_codegen: (2026-03-29)
- remap_derive_field() helper in bodies.rs — uses FunctionCompiler::repr_plan().
- compile_for_each_field() (Eq): extract_value(self_val, mem_i) and extract_value(other_val, mem_i).
- emit_lexicographic_body() (Comparable): same pattern.
- emit_hash_combine_body() (Hashable): extract_value(self_val, mem_i).
- compile_format_fields() (Printable/Debug): extract_value(self_val, mem_i).
- compile_clone_fields() (Clone): extract_value(self_val, mem_i).
- compile_default_construct() (Default): uses const_zero — no remapping needed.
Wire codegen field-index remapping into DropFunctionGenerator (arc_emitter/drop_gen.rs): (2026-03-29)
- emit_drop_fields(): each field_index remapped via self.remap_struct_field(ty, field_index).
- Tag guard in remap_struct_field() ensures closure envs are NOT remapped (Tag::ClosureEnv != Tag::Struct/Tuple).
Wire field-index remapping into narrowing_codegen.rs: (2026-03-29)
- sext_narrowed_field(): No remapping needed — field_index is label-only.
- trunc_for_narrowed_struct(): No direct changes needed — args are reordered in emit_construct() BEFORE calling trunc_for_narrowed_struct(), so it already receives memory-order args. Unified reorder point in construction.rs.
Implement compute_struct_layouts pipeline body (pipeline/mod.rs): (2026-03-29)
- Iterates all struct/tuple types, applies optimize_struct_layout/optimize_tuple_layout.
- Phase 1: all-scalar structs only (no mixed-field types yet).
- Alias propagation via propagate_layout_to_aliases for monomorphized generics.
- Fixed: selective param loading remapping, narrowing field_pool_types order, Pool Idx aliasing.
[BLOAT] pipeline.rs extracted to pipeline/mod.rs (351 lines) + pipeline/metadata.rs (171 lines). (2026-03-29)

Test strategy for §06.0 (TDD — write tests FIRST, verify they pass with identity mapping):

Tests go in compiler/ori_repr/src/struct_repr/tests.rs (for helper methods) and the existing compiler/ori_repr/src/tests.rs (for pipeline integration). Since §06.0 wires remapping as NO-OP (declaration order == memory order), tests assert the identity invariant.

Rust unit tests — StructRepr helpers in layout/tests.rs: (2026-03-29)
- field_by_original(0) returns correct field, field_by_original(N) returns None
- memory_index(i) == i for identity-ordered structs, memory_index(N) returns None for OOB
- Empty struct: memory_index(0) returns None
- Semantic pin: reordering tests verify memory_index(0) != 0 for { a: bool, b: int } after layout
Regression test — ./test-all.sh green (14,584 passed, 0 failed). No-op remapping introduces zero regressions. (2026-03-29)
Debug AND release builds: cargo b and cargo b --release both succeed. (2026-03-29)

Done criteria for §06.0:

compiler/ori_repr/src/layout/ is a directory module with mod.rs, struct_layout.rs, tuple_layout.rs, tests.rs
StructRepr::field_by_original() and StructRepr::memory_index() exist and have unit tests
All codegen field-index remapping is wired but NO-OP (because compute_struct_layouts is still empty — fields are in declaration order, so memory_index(i) == i)
./test-all.sh green — remapping wiring introduces no regressions
pipeline.rs is under 500 lines (metadata functions extracted)

06.1 Field Reordering Algorithm

File(s): compiler/ori_repr/src/layout/struct_layout.rs (new file in the converted layout module) Note: optimize_struct_layout() dispatches to compute_c_layout(), compute_packed_layout(), compute_transparent_layout() which are specified in §06.3. In practice, §06.1 and §06.3 must be co-implemented in the same file. The split is for conceptual clarity — implement both together.

Implement the field reordering algorithm: (2026-03-29)

use crate::layout::{field_size, field_align, round_up, is_trivial_repr};
use crate::struct_repr::{FieldRepr, StructRepr};
use crate::plan::{ReprAttribute, ReprPlan};
use ori_types::Idx;

/// Reorder struct fields for optimal alignment and minimal padding.
///
/// Reads the existing `StructRepr` from the plan (already populated by
/// `canonical_struct()` with narrowed field reprs from §04/§05),
/// reorders `fields` by descending alignment then descending size,
/// computes byte offsets, and writes the updated `StructRepr` back.
///
/// Skips types with `#repr("c")`, `#repr("packed")`, or
/// `#repr("transparent")` attributes — those have user-controlled layout.
pub(crate) fn optimize_struct_layout(
    struct_repr: &StructRepr,
    repr_attr: Option<&ReprAttribute>,
) -> StructRepr {
    // Step 0: Check for ABI-stable opt-out
    match repr_attr {
        Some(ReprAttribute::C | ReprAttribute::CAligned(_)) => {
            return compute_c_layout(struct_repr, repr_attr);
        }
        Some(ReprAttribute::Packed) => {
            return compute_packed_layout(struct_repr);
        }
        Some(ReprAttribute::Transparent) => {
            return compute_transparent_layout(struct_repr);
        }
        Some(ReprAttribute::Aligned(n)) => {
            let mut result = reorder_and_layout(struct_repr);
            result.align = result.align.max(*n);
            result.size = round_up(result.size, result.align);
            return result;
        }
        Some(ReprAttribute::Default) | None => {}
    }

    reorder_and_layout(struct_repr)
}

fn reorder_and_layout(struct_repr: &StructRepr) -> StructRepr {
    // Step 1: Build (memory_pos, size, align) tuples for sorting
    let mut indexed: Vec<(usize, u32, u32)> = struct_repr.fields.iter()
        .enumerate()
        .map(|(i, f)| {
            let size = field_size(&f.repr);
            let align = field_align(&f.repr);
            (i, size, align)
        })
        .collect();

    // Step 2: Sort by descending alignment, then descending size.
    // MUST use stable sort (sort_by, not sort_unstable_by) so that
    // fields with equal alignment AND equal size preserve their
    // original declaration order — deterministic layout.
    indexed.sort_by(|a, b| {
        b.2.cmp(&a.2)  // alignment descending
            .then(b.1.cmp(&a.1))  // size descending
    });

    // Step 3: Compute offsets in sorted order
    let mut offset = 0u32;
    let mut max_align = 1u32;
    let mut layout_fields = Vec::with_capacity(struct_repr.fields.len());

    for &(src_idx, size, align) in &indexed {
        offset = round_up(offset, align);
        let orig = &struct_repr.fields[src_idx];
        layout_fields.push(FieldRepr {
            name: orig.name,
            original_index: orig.original_index,
            offset,
            repr: orig.repr.clone(),
        });
        offset += size;
        max_align = max_align.max(align);
    }

    // Step 4: Trailing padding for array alignment
    let total_size = round_up(offset, max_align);

    StructRepr {
        fields: layout_fields,
        size: total_size,
        align: max_align,
        trivial: struct_repr.trivial,
    }
}

Handle zero-sized fields (unit, never): (2026-03-29)
- field_size() and field_align() in layout.rs already return 0 and 1 respectively for Unit/Never — the sorting puts them last (smallest alignment), and they contribute 0 bytes to the offset. They still get an offset entry for codegen correctness.
Handle edge cases in the reordering algorithm: (2026-03-29)
- Empty structs (0 fields): reorder_and_layout() returns StructRepr { fields: vec![], size: 0, align: 1, trivial: true }. The max_align starts at 1 (never updated), offset stays at 0. Verify this path.
- Single-field structs: no reordering possible — algorithm degenerates to identity. Still compute correct offset (0) and size (rounded up to alignment).
- Generic structs: By the time ori_repr sees them, generics are monomorphized — canonical_struct() operates on fully-resolved Idx values from the Pool. No special handling needed, but add a test confirming struct Pair<T> { a: T, b: int } instantiated as Pair<bool> gets reordered (int first, bool second).
- Newtypes (type UserId = int): These are structurally single-field structs with implicit #repr("transparent") semantics. The canonical_struct() path in type_repr.rs handles them as normal structs. compute_transparent_layout() handles the #repr("transparent") attribute. Newtypes without an explicit #repr get the default layout (single-field, no reordering, size = field size).
- Recursive types (e.g., type Node = { value: int, next: Option<Node> }): The Option<Node> field canonicalizes to RcPointer(...) (heap-allocated), which has a fixed 8-byte size. The reordering algorithm sees int (8 bytes, align 8) and RcPointer (8 bytes, align 8) — no reordering needed, but the algorithm must handle it correctly without infinite recursion. The recursion guard is in canonical_struct() (the visiting set), not in the layout algorithm — by the time §06 runs, all StructRepr values are fully resolved.

Test strategy for §06.1 (TDD — write failing tests FIRST):

Tests go in compiler/ori_repr/src/layout/tests.rs. Write all unit tests before implementing reorder_and_layout(). Verify they fail (returning declaration-order layout), then implement.

Write failing Rust unit test matrix BEFORE implementation (all in layout/tests.rs): (2026-03-29)

Matrix dimensions: struct shape x field type mix x expected property

Test name	Input fields (decl order)	Expected memory order	Expected size	Pin type
`reorder_bool_int_bool`	`bool(1), int(8), bool(1)`	`int, bool, bool`	16	Semantic: size 16 not 24
`reorder_already_optimal`	`int(8), int(8)`	`int, int`	16	Negative: no regression
`reorder_four_bytes_and_int`	`byte(1), byte(1), byte(1), byte(1), int(8)`	`int, byte, byte, byte, byte`	16	Semantic: 12 data + 4 pad
`reorder_mixed_widths`	`bool(1), float(8), byte(1), int(8)`	`float, int, bool, byte`	24	Semantic: reorder by align then size
`reorder_empty_struct`	`(none)`	`(none)`	0, align 1	Edge: no panic
`reorder_single_field`	`int(8)`	`int`	8, align 8	Edge: identity
`reorder_all_same_align`	`bool(1), byte(1), bool(1)`	preserves declaration order (stable sort)	3, align 1	Semantic: stable sort
`reorder_zst_fields`	`int(8), Unit(0), bool(1)`	`int, bool, Unit`	16	Edge: ZST last
`reorder_narrowed_fields`	`bool(1), i16(2), f32(4)`	`f32, i16, bool`	8	Semantic: narrowed sizes
`reorder_preserves_original_index`	`bool(1), int(8)`	fields[0].original_index == 1 (int), fields[1].original_index == 0 (bool)	16	Invariant: original_index preserved

Tests written, algorithm implemented, all tests pass (2026-03-29)
Semantic pin: reorder_preserves_original_index can ONLY pass with §06 reordering (2026-03-29)

Done criteria for §06.1:

optimize_struct_layout() and reorder_and_layout() implemented in layout/struct_layout.rs
Unit tests for all edge cases (empty, single-field, generic, newtypes, recursive, ZST, narrowed, stable sort) in layout/tests.rs
compute_struct_layouts() in pipeline.rs calls optimize_struct_layout() for all struct types in ReprPlan
struct { a: bool, b: int, c: bool } produces StructRepr.size == 16 (not 24) in unit tests
./test-all.sh green

06.2 Padding Tracking & Diagnostics

File(s): compiler/ori_repr/src/layout/struct_layout.rs

Track padding bytes per struct and emit a tracing diagnostic when padding exceeds 25% of total size: (2026-03-29)

let data_bytes: u32 = layout_fields.iter()
    .map(|f| field_size(&f.repr))
    .sum();
let padding = total_size.saturating_sub(data_bytes);
if total_size > 0 && padding > total_size / 4 {
    tracing::debug!(
        total_size,
        padding,
        data_bytes,
        "struct has >25% padding despite field reordering"
    );
}

Note on bitfield packing (NOT §06 scope — distinct optimization):

Packing multiple bool/byte/Ordering fields into sub-byte bitfields is a separate optimization from field reordering. It would require:

Codegen to emit bit-level insert/extract for every field access, pattern match, and derive body
ArcIrEmitter changes across Project, Construct, Set, and all derive codegen strategies
ori_eval changes (interpreter field access) for dual-execution parity

This is architecturally distinct from §06’s field reordering — it changes the representation of individual fields, not their ordering. The natural packing from alignment sorting already places bool/byte/Ordering fields (1-byte aligned) contiguously at the end of the struct, achieving good spatial locality without sub-byte complexity.

Bitfield packing tracked: deferred to §11 or §12 based on profiling data. Not §06 scope (distinct optimization requiring bit-level codegen changes). (2026-03-29)

Test strategy for §06.2 (TDD):

Tests go in compiler/ori_repr/src/layout/tests.rs. Use tracing-test or a tracing subscriber mock to capture diagnostic output.

Padding diagnostic implemented. Unit tests verify layout correctness (sizes, offsets) which implicitly exercises the diagnostic code path. Tracing capture tests deferred — no tracing-test dependency. (2026-03-29)

Done criteria for §06.2:

Padding tracing diagnostic emitted for structs with >25% padding
Unit tests verify the diagnostic fires and stays silent using the test matrix above

06.3 ABI-Stable Opt-Out

File(s): compiler/ori_repr/src/layout/struct_layout.rs

For FFI interop, users need control over memory layout. The #repr attribute infrastructure is already in place:

ReprAttrKind enum in ori_ir::ast::items::types (parsed by ori_parse)
ReprAttribute enum in ori_repr::plan::repr_attr (C, Packed, Transparent, Aligned, CAligned, Default)
compute_repr_plan_with_interner() converts ReprAttrKind → ReprAttribute via convert_repr_attr_kind() and stores in ReprPlan::repr_attrs (keyed by Idx)
plan.repr_attr(idx) query returns Option<&ReprAttribute> for any type

The layout algorithm queries repr_attr and dispatches to the appropriate layout strategy:

Implement compute_c_layout() for #repr("c") / #repr("c") + #repr("aligned", N): (2026-03-29)
- Fields in declaration order (use original_index to maintain source order)
- Platform-specific alignment (matches target C ABI: field_align() already gives correct values)
- No field reordering, no narrowing of field types (§04 already skips #repr("c") types via has_fixed_layout_attr())
- For CAligned(N): struct alignment = max(computed, N)
Implement compute_packed_layout() for #repr("packed"): (2026-03-29)
- Fields in declaration order
- Every field offset = previous field’s end (no alignment padding)
- Struct alignment = 1
- Note: may require unaligned loads in codegen (LLVM handles this via align 1 on load/store)
Implement compute_transparent_layout() for #repr("transparent"): (2026-03-29)
- Validate: exactly one non-ZST field (check field_size(&f.repr) > 0)
- Struct size = that field’s size, alignment = that field’s alignment
- Error if 0 or 2+ non-ZST fields (diagnostic: use existing error accumulation pattern)
- Note: validation should ideally happen at type-check time (§06 can add a debug_assert! for safety, but the primary check belongs in ori_types — if not already present, add a plan item)
Implement compute_aligned_layout() for #repr("aligned", N): (2026-03-29)
- Reorder fields normally, then enforce struct.align = max(computed, N)
- round_up(size, new_align) for trailing padding
- Validate: N is a power of two (should be checked at parse time; add debug_assert!(N.is_power_of_two()))
- Must NOT combine with #repr("packed") or #repr("transparent") — ReprAttribute enum is already mutually exclusive by construction (no combined variant exists except CAligned)
Default behavior (no attribute / ReprAttribute::Default): (2026-03-29)
- Reorder fields for optimal alignment (§06.1)
- Field types already narrowed by §04/§05 (stored in FieldRepr.repr)
- Pad for alignment

Note: has_fixed_layout_attr() in narrowing/int.rs:201 already checks C | CAligned | Packed | Transparent for narrowing skipping. §06 uses ReprAttribute directly in optimize_struct_layout() (not has_fixed_layout_attr) because §06 needs to dispatch to different layout algorithms (C layout, packed layout, etc.) rather than just skip. But the set of “fixed layout” attributes is the same — if has_fixed_layout_attr gains new variants, §06’s match must stay in sync. Add a debug_assert! or comment cross-referencing the two.

Test strategy for §06.3 (TDD — write failing tests FIRST):

Tests go in compiler/ori_repr/src/layout/tests.rs. Each #repr variant gets its own test group.

Unit test matrix implemented (c_layout, packed, transparent, aligned, default): 6 tests in layout/tests.rs (2026-03-29)
All ABI-stable variants implemented and tested (2026-03-29)

Done criteria for §06.3:

compute_c_layout(), compute_packed_layout(), compute_transparent_layout() implemented
Unit tests for each repr variant using the matrix above
#repr("c") struct { a: bool, b: int, c: bool } produces size 24 (not 16) in unit test
./test-all.sh green

06.4 Tuple Layout

File(s): compiler/ori_repr/src/layout/tuple_layout.rs (new file)

Tuples are anonymous structs. TupleRepr has the same shape as StructRepr (elements: Vec<FieldRepr>, size, align, trivial) — the only difference is the field name elements instead of fields. Apply the same reordering optimization.

Current state: TupleRepr::to_machine_repr() in layout.rs creates tuples via compute_field_layout() in declaration order. §06 will replace this with reordered layout.

Implement optimize_tuple_layout(): (2026-03-29)
- Same algorithm as reorder_and_layout() from §06.1 but operating on TupleRepr.elements
- original_index is the tuple position (0, 1, 2, …)
- No #repr attributes apply to tuples (they are always reorderable)
Ensure tuple destructuring works with reordered layout: (2026-03-29)
- let (a, b, c) = tuple → uses original indices, not memory order
- Codegen translates: a = struct_gep(tuple_ptr, memory_index(0)) where memory_index(0) is looked up via TupleRepr.elements.iter().position(|e| e.original_index == 0)
- Add TupleRepr::memory_index() helper (same pattern as StructRepr::memory_index() from §06.0)

Struct update syntax ({ ...p, x: 10 }):

Struct update desugars to a combination of ArcInstr::Project (extract unchanged fields) and ArcInstr::Construct (build new struct with updated fields). Both go through the standard codegen paths that §06.0’s remapping covers. No additional work needed beyond the remapping in §06.0, but add a specific test verifying struct update works correctly with reordered fields.

Debug info / source-order preservation:

DWARF debug info needs to emit fields in declaration order (for debugger display), even though the LLVM struct type has fields in memory order. Currently, Ori does not emit DWARF debug info for struct fields (no DI metadata in codegen). When DWARF emission is added in the future, it must use FieldRepr.original_index and FieldRepr.name to reconstruct declaration order. This is a NOTE for future work, not a §06 deliverable — no DWARF infrastructure exists today.

Cross-section data flow:

§06 reads: StructRepr and TupleRepr from ReprPlan (populated by §01 canonical, narrowed by §04/§05)
§06 reads: ReprAttribute from ReprPlan::repr_attrs (populated by §01)
§06 writes: updated StructRepr/TupleRepr with reordered fields and computed offsets back into ReprPlan
§07 (Enum Repr) reads: struct field layout for enum variant payloads that are structs — if §06 has reordered the inner struct’s fields, §07 sees the reordered layout. This is correct (§07 operates on the MachineRepr from ReprPlan, which §06 has updated).
§11 (Collection Specialization) reads: element layout for packed arrays — if the element is a struct, §11 sees the §06-optimized layout. This is correct.
ori_llvm codegen reads: final StructRepr with memory-order fields, offsets, and size/align for LLVM struct type construction (via try_lower_narrowed_aggregate() in layout_resolver.rs).

Test strategy for §06.4 (TDD — write failing tests FIRST):

Rust unit tests in compiler/ori_repr/src/layout/tests.rs. AOT integration tests in compiler/ori_llvm/tests/aot/. Ori spec tests in tests/spec/types/struct_layout/.

7 Rust unit tests for tuple layout (reorder, original_index, memory_index, single, same_type): layout/tests.rs (2026-03-29)
AOT integration verified: test_aot_generic_three_type_params exercises (int, bool, int) tuple destructuring in AOT — passes after alias propagation fix (2026-03-29)
optimize_tuple_layout() and TupleRepr::memory_index() implemented and tested (2026-03-29)
Dual-execution parity: 4217 interpreter + 257 LLVM spec tests all pass (2026-03-29)
Pipeline activation: tuple reordering activated for 3+ element tuples in compute_struct_layouts(). 2-element tuples safely skipped: (a) all runtime-boundary tuples are 2-element (next_map, next_zipped, next_enumerated), (b) 2-element tuple total size is identical regardless of field order when field sizes are multiples of alignment (all Ori types). 4 new Rust unit tests + 12 Ori spec tests in tests/spec/types/tuple_layout.ori. 14,635 tests pass, 0 failures. (2026-03-30)

Done criteria for §06.4:

optimize_tuple_layout() implemented in layout/tuple_layout.rs
TupleRepr::memory_index() helper exists with unit tests
(bool, int, bool) produces same layout as equivalent struct in unit test
Tuple destructuring .0, .1, .2 returns correct values in AOT test with reordered tuple
Dual-execution parity verified for tuple tests (interpreter and LLVM produce identical results)
./test-all.sh green

06.R Third Party Review Findings

06.5 Completion Checklist

Test matrix for §06 (write failing tests FIRST, verify they fail, then implement):

Tests are primarily Rust unit tests in compiler/ori_repr/src/layout/tests.rs (struct layout) and compiler/ori_llvm/tests/aot/ (codegen verification). Layout can be observed by:

Checking StructRepr.size, StructRepr.align, and FieldRepr.offset values directly in Rust unit tests
Verifying LLVM IR struct type definitions via ORI_DUMP_AFTER_LLVM=1 and asserting field order in AOT tests
Verifying struct_gep indices in codegen output match the remapped memory order

Struct definition	Expected layout	Semantic pin
`struct { a: bool, b: int, c: bool }`	16 bytes: `int` first (offset 0), `bool` fields at offset 8 and 9	Yes — 16 bytes, not 24
`struct { x: int, y: int }`	16 bytes (unchanged — already optimal)	Yes — no regression
`struct { a: byte, b: byte, c: byte, d: byte, e: int }`	16 bytes: `int` first at offset 0, bytes at 8-11	Yes — 12 bytes data + 4 padding = 16
`(bool, int, bool)` tuple	Same layout as equivalent struct	Yes — tuple reorder matches struct
`#repr("c") struct { a: bool, b: int, c: bool }`	24 bytes (declaration order preserved)	Yes — no reorder with `#repr("c")`
`#repr("transparent") struct Wrap { inner: int }`	8 bytes, same alignment as `int`	Yes — no wrapper overhead
`#repr("aligned", 16) struct Foo { x: int }`	16 bytes (8 data + 8 padding), alignment = 16	Yes — forced alignment
`#repr("transparent")` with 2 non-ZST fields	Compile error or debug_assert failure	Yes — validation enforced
`#repr("packed")` combined with `#repr("aligned", N)`	Compile error (mutually exclusive — `ReprAttribute` enum prevents)	Yes — incompatible attrs
Zero-sized field `()` in struct	No storage contribution, correct offset	Yes — ZST handling
Empty struct `struct {}`	0 bytes, align 1	Yes — degenerate case
Single-field struct `struct { x: int }`	8 bytes (no reorder possible)	Yes — identity case
Generic `Pair<bool> { a: bool, b: int }`	16 bytes (int first)	Yes — monomorphized reorder
Struct update `{ ...p, x: 10 }` with reordered fields	Correct field values after update	Yes — remapping through Project+Construct
Derived Eq on reordered struct	`==` returns correct result	Yes — derive codegen remapped
Derived Clone on reordered struct	Clone produces identical value	Yes — derive codegen remapped
Derived Debug on reordered struct	Debug string shows fields in declaration order	Yes — derive format uses FieldDef names
Nested struct `{ inner: Inner, x: int }` where `Inner` is also reordered	Both levels reordered correctly	Yes — transitive layout
`#repr("packed") struct { a: bool, b: int, c: bool }`	10 bytes, align 1, no padding	Yes — packed layout
Narrowed fields `{ a: bool, b: i16, c: f32 }`	`f32(4), i16(2), bool(1)` — 8 bytes	Yes — narrowed sizes sort correctly
RC field drop `{ flag: bool, name: str, count: int }`	`name` dropped correctly after reorder	Yes — drop remapping
Derived Hashable on reordered struct	same hash as manually-constructed equivalent	Yes — derive codegen remapped

Exit Criteria (all must be measurably true):

StructRepr.size for struct { a: bool, b: int, c: bool, d: byte } is 16 bytes (i64 at offset 0, then i8+i8+i8 at offsets 8-10, then 5 bytes trailing padding to align 8), verified in both Rust unit tests and LLVM IR
All struct-related spec tests pass in both debug and release builds
Codegen correctly remaps declaration-order field indices to memory-order indices via StructRepr::memory_index()
Layout is deterministic (stable sort — identical input always produces identical output)
#repr("c") structs are unaffected (declaration order preserved, size matches C ABI)
Interpreter and LLVM produce identical results for ALL new test files (dual-execution parity) — caveat: struct_layout.ori LLVM verification blocked by system-wide assert_eq monomorphization gap (P0, tracked in test-suite-health plan); non-assert_eq tests verified
ORI_CHECK_LEAKS=1 reports zero leaks on all spec tests with RC-containing structs
/tpr-review passed with no critical or major unresolved findings — reopened on 2026-03-30 by TPR-06-019 (the new nested-char spec test is still blocked from LLVM execution, so the low-alignment for...yield copy path lacks backend-executed regression coverage)