Fusion emits identity trampolines that never inline (dead inline_adapters flag); de-export fusion-vestigial symbols

[avrabe]

Fusion emits identity trampolines that never inline (dead inline_adapters flag); de-export fusion-vestigial symbols

Context

gale's dissolved-codegen work (pulseengine/gale#97) found that un-inlined forwarding wrappers cost ~2× cycles on tiny functions (an extra bl + stack round-trip + second prologue). For the meld-fused demonstrator path (gale-app-demo + gale-kiln → meld fuse --memory shared --address-rebase → loom → synth → 668 B native, gale benches/gust/build-fused.sh), meld introduces the same pathology structurally.

Finding 1 — identity trampolines + a dead inline_adapters flag

meld emits one adapter function per cross-component call edge and rewires the caller to it (meld-core/src/lib.rs:wire_adapter_indices:372; adapter_base :380). For the common shared-memory, no-transcode, no-resource case meld emits a pure forwarding thunk — generate_direct_adapter (adapter/fact.rs:552-567): re-push every param, call $target, end. Left un-inlined into native, each becomes the bl-chain + frame round-trip we measured.

AdapterConfig.inline_adapters (adapter/mod.rs:35) is set true (lib.rs:296) but read nowhere in meld-core (grep finds only the definition + assignment). Ask: honor it — when generate_adapter selects the identity-trampoline case (analyze_call_site → direct adapter, same memory, no post-return/resource ops), rewire the import directly to target_func instead of emitting a thunk. Sound (the body only forwards), and it's the leanest output — fewer functions for loom/synth, no thunk for loom to inline (and loom currently doesn't inline small multi-site funcs anyway — see pulseengine/loom issue).

Finding 2 — de-export fusion-vestigial symbols (generalize meld#298)

gale's build-fused.sh must manually grep -vE '\(export "(cabi_realloc|gale:kernel|__data_end|__heap_base)' AFTER meld so loom/synth can DCE the now-dead canonical-ABI/realloc path. meld emits these exports (merger.rs cabi_realloc :1218-1256). Once fusion closes the import graph, any export that existed only to satisfy a now-resolved cross-component import is vestigial. Ask: de-export them at fusion time (a --strip-vestigial flag or default) — generalizes meld#298 beyond cabi_realloc, removes the manual strip step.

Not meld's gap (honest)

• The gust_mix 2.81× number itself is not meld's — that module never goes through meld fuse.
• --address-rebase is free on scalar access: the base folds into the static load/store offset immediate (rewriter.rs:convert_memarg:585-587; data segments rebased statically segments.rs:rebase_const_expr_value:427). Runtime i32.add is inserted only for dynamic-address bulk ops (memory.copy/fill/init, rewriter.rs:append_rebased_address:543), gated on base != 0 and only in functions that contain such ops. Not a per-access tax.
• Per-component handle tables (branch feat/per-component-handle-tables) aren't wired into codegen yet (only reexporter_components exists) — zero overhead today, and irrelevant to the gust composition.

Boundary / beat-LLVM

Keep the meld/loom split: meld emits minimal verifiable structure, loom does cost-based inlining + layout DCE (build-fused.sh already runs loom --passes inline). The exception is Finding 1 — not emitting provably-no-op indirection isn't "doing loom's job," it's not creating garbage. meld's real leverage: fusion turns cross-"object" calls into inlinable intra-module calls (the LTO win, structurally) and a single flat address space with no per-access tax — and the adapter/fact.rs + component-provenance machinery can forward typed canonical-ABI facts (owned vs borrowed, layouts) as proof-carrying metadata that a native multi-object link discards. Lean into that; just don't interpose the identity trampoline.

Refs: meld#298 (cabi_realloc de-export — Finding 2 generalizes it). Pipeline: gale benches/gust/build-fused.sh.

[avrabe]

Issue-hunt pass — Finding 1 implemented (oracle-gated); Finding 2 triaged

Finding 1 — dead inline_adapters / identity trampolines: DONE (branch fix/298-dead-allocator-dce)

Verified the claim: inline_adapters was defined (adapter/mod.rs), set true (lib.rs), and read nowhere. Implemented honoring it:

• A Direct adapter that is a pure identity trampoline (body = local.get*; call target; end) now carries inline_target: Some(target_func), and wire_adapter_indices wires the caller's import straight to the target instead of to the thunk. The unreferenced thunk is left for loom to DCE.
• No re-index — the thunk slot is preserved, only the caller's edge moves — so all adapter index math is untouched (zero corruption risk). This is the safe form of "rewire directly to target_func."
• Identity condition (fail-safe → keep thunk on any doubt): class == Direct && resource_rep_calls.empty() && resource_new_calls.empty() && callee_post_return.is_none(). One subtlety worth recording: the Direct else branch still emits call post_return when has_post_return && result_count == 0, so post-return had to be excluded entirely, not just the result>0 case — otherwise direct-wiring would silently skip the post-return cleanup.
• New FusionStats.adapters_inlined for observability (the gale pipeline can see inlining fired).

Oracle: cross_component_call::test_304_identity_direct_adapter_is_inlined fuses the real wac-composed consumer→provider fixture, asserts ≥1 identity adapter inlined + the fused module validates. Behaviour preserved across cross_component_call, adapter_safety, runtime_intra_adapter, runtime_from_exports, wit_bindgen_runtime (73), and golden_e2e Tier-B behavioural equivalence on the same fixture.

Note on the boundary you drew: agreed — this isn't "doing loom's job," it's not creating the garbage. meld now emits no identity indirection; loom still owns cost-based inlining of real thunks.

Finding 2 — de-export fusion-vestigial symbols: triaged secondary

Generalizes #298, which was reclassified secondary after #300 committed model 2 (multi-memory structural isolation) as the dissolved-MCU path; the --memory shared de-export work is deprioritized accordingly. The gale:kernel/__data_end/__heap_base generalization is real but sits behind the structural-isolation path. Tracking with #298; not in this pass.

The honest caveats in your "Not meld's gap" section (gust_mix not via meld; --address-rebase free on scalar access; per-component handle tables not wired) — noted, no action needed.