Make components small: custom-section GC + component-level reachability GC + canon seam dissolution

[avrabe]

Problem

WebAssembly Components are large. The fixtures in this repo are ~2.3 MB each (calculator.wasm, datetime.wasm, hello_rust_host.wasm). component_optimizer.rs today optimizes the core module code inside a component (and does type-dedup + adapter/async specialization), but two large size sources are untouched:

1. Custom sections are never stripped. There is no production custom-section GC for components (the custom_sections: vec![] references are test fixtures only). Components ship with embedded WIT component-type metadata, producers, name, and DWARF .debug_* sections — none of which affect execution semantics, all of which inflate the binary.
2. No component-level reachability GC. Canonical optimization is stubbed: component_optimizer.rs:624 reads // Future: Inline trivial lift/lower pairs. Unused type defs, aliases, canon lift/lower functions, and core funcs unreachable from the component's exports are not pruned across the instantiation/alias graph.

Proposal — "make components small", in loom's provably-correct idiom

Phases, ordered by safety so they sequence cleanly after the behavioral gate (#238):

Phase A — custom-section GC (cheapest, biggest, safe without #238).
Strip producers, name, and .debug_* (DWARF) sections; opt-in strip of the component-type metadata section (does not affect execution, but tooling/wit-component introspection depends on it — hence opt-in, default-preserve). Custom sections are semantically inert ⇒ removal is trivially sound and behavioral-gate-checkable.

Phase B — component reachability GC (structural, sound).
The component analog of eliminate_dead_functions: mark-and-sweep over the component's export → instance → alias → canon → core-func graph; drop everything unreachable. Must be #196-safe — keep exports, start, and indirect/element-table targets live; conservative on parse failure.

Phase C — canonical ABI seam dissolution (needs #238).
Fold trivial lift/lower pairs and pass-through fused adapters at the component boundary (the line-624 TODO). This is the #219 seam at the component ABI; canon glue is hard to Z3-verify, so it rides the behavioral differential (#238) as its gate.

Dependencies / sequencing

• Phase A: independent, can ship first.
• Phase B: structural; behavioral gate (Behavioral differential as an optimization gate (self-certify non-Z3-backstoppable transforms) #238) recommended as backstop.
• Phase C: requires Behavioral differential as an optimization gate (self-certify non-Z3-backstoppable transforms) #238.

Acceptance

• Phase A: measurable byte reduction on the component fixtures with byte-for-byte identical execution (differential-clean)
• Phase B: unreachable types/aliases/canon/core-funcs pruned; exports + indirect targets preserved; dogfood + components still validate and run identically
• Phase C: trivial lift/lower folds gated by Behavioral differential as an optimization gate (self-certify non-Z3-backstoppable transforms) #238
• CLI reports component section-level size breakdown (code vs types vs custom) so wins are attributable

[avrabe]

Data point from the jess MCU-lowering path (falcon → STM32F100/Cortex-M3), loom v1.1.16.

Measuring loom's effect on the code section of the meld-fused falcon flight component (falcon-flight-v1.94), since flash/SRAM is the binding constraint on the F100 (8 KB SRAM):

variant	code section	Δ vs fused
meld-fused (loom input)	68 322 B	—
loom optimize (default: all passes, islands=1)	79 346 B	+16.1 %
loom optimize --islands 4	80 872 B	+18.4 %
loom optimize --passes … (default set minus inline)	68 322 B	+0.0 %

Two observations relevant to "make components small":

1. All of the growth is the inline pass, and there's no size-budgeted / -Os / MCU profile — the only way to avoid the +16 % today is to hand-enumerate --passes and drop inline, which also loses the inlining that does help (e.g. the gust hot-path seam in Seam-inlining not firing on the gust hot path (mix/transition survive as calls) #226). A size-aware profile (or a size budget on inline) would let MCU targets keep the useful inlines without the blanket inflation.

2. --islands 4 returned a larger module than the islands=1 default (80 872 > 79 346 B), even though --islands is documented as "picks the smallest verified result." The candidate set of pass-orderings it searches doesn't appear to include (or beat) the default pipeline for size, so on this input it's strictly worse on the metric it advertises.

Happy to share the fused .wasm if useful. This sits alongside #226/#219 on the LLVM-LTO-parity / synth#494 0.7× track — on a no-FPU M3, code that doesn't fit the flash/cache budget is exactly where the parity gap opens.

[avrabe]

Calibrating my previous comment — I measured bytes, not cycles, so I should not imply the inlining inflation is a performance loss. The opposite is likely: inlining removes call overhead and is plausibly a contributor to the synth#494 0.7× goal. Two corrections:

• The size→speed coupling is target-specific. On the STM32F100 (Cortex-M3) there's no I-cache and flash is 0-wait-state at its 24 MHz max, so +16% code is ~speed-neutral there — and falcon's real target is the i.MX RT1176 M7 (16 KB I-cache), where the inline/size tradeoff is a genuine choice, not free. My "flash/cache budget" phrasing was wrong for the M3 case.
• So the actionable parts of my report are narrower than I made them sound: (a) the objective --islands N behavior (returns a larger result than islands=1, against the "smallest verified result" contract), and (b) the absence of a size/speed knob (-Os/MCU profile) so a target with an i-cache can opt for the smaller variant when measured cycles favor it. The +16% itself is just data, not a defect.

I don't yet have a cycle count to say whether the inlines help or hurt net speed on the M7 — that needs an actual instruction-count benchmark. Happy to run one if useful.