inline_functions never inlines small multi-call-site leaves (size<10 OR-term shadows MULTI_CALL_SITE_LIMIT); + optimize CLI lacks whole-function DCE

[avrabe]

inline_functions: small multi-call-site leaves are never inlined — size < 10 OR-term shadows MULTI_CALL_SITE_LIMIT (dead constant); + loom optimize has no whole-function DCE

Context

gale's gust codegen bench (pulseengine/gale#97) measures dissolved gust_mix at 2.81× native LLVM cycles. A large share is an export wrapper that bls an inner body (gust_wasm_scout::mix); they're never merged, so synth lowers two functions + a call + a stack round-trip where native has one.

Root cause (verified live on the real module, loom 1.1.14)

The inner mix is 23 instructions, fully modelable (local.tee+select), with 2 call sites (the gust_mix export wrapper and gust_poll). It is never inlined — loom optimize --passes inline and full loom optimize both leave 6 functions with gust_mix still calling it.

The candidate predicate, loom-core/src/lib.rs:13476:

if (call_count == 1 || size < 10) && size < limit {
    inline_candidates.push(*func_idx);
}

With call_count==2 and size==23, both OR terms are false → never a candidate, never offered to the Z3 gate. MULTI_CALL_SITE_LIMIT = 50 (lib.rs:13469-13475) is dead code: it's only read when call_count != 1, but in that branch the OR already requires size < 10, so nothing in [10,50) ever reaches size < limit. The "small function cheap from multiple sites" doc comment (13456-13462) describes only the size<10 behavior.

This is NOT size/modelability (23 < 50, fully modelable), NOT Z3 revert (never reached), NOT export-caller protection (none exists in the candidate/inline loops 13429-13540), NOT the fixpoint guard.

Fix

if size < limit {   // let the site-count-dependent budget govern; Z3 (13532) stays the backstop
    inline_candidates.push(*func_idx);
}

This admits a 23-insn 2-site leaf under MULTI_CALL_SITE_LIMIT=50; the existing per-inline Z3 verify_or_revert (13532) bounds correctness risk.

Companion finding — loom optimize has no whole-function DCE (must land with the above)

Multi-site inlining duplicates the body into both callers but leaves the original orphaned, growing the module. The remover eliminate_dead_functions (fused_optimizer.rs:1923/2025) is reached only via optimize_module Phase 0 / run_fused_optimizations (fused_optimizer.rs:170) — optimize_command never calls it (loom-cli/src/main.rs:489-652 runs a hand-rolled pass list whose dce = eliminate_dead_code lib.rs:7149, intra-function only). So an orphaned function survives every loom optimize run. Ask: expose module-level dead-function elimination as a CLI pass (e.g. dce-functions) after inline, or route the CLI default through optimize_module.

Secondary (lower impact, real)

• Inliner emits a redundant arg-copy: inline_calls_in_block (lib.rs:13686-13688) unconditionally local.sets each param into a fresh temp even when the single arg is already stack-positioned → a local.set N; … local.get N round-trip downstream must clean. Add argument-forwarding when the arg is a local.get with no intervening write.
• simplify_locals can't clean it up: discards ALL equivalences if the function has any If/Block/Loop (lib.rs:8905-8919), and removes the equivalence on every LocalTee (8997-9000). So the arg-copy survives the full pipeline.

Not loom's gap (filed at synth)

The register-materialized shift (movw r4,#8; lsl.w r5,r3,r4) and the materialized-bool select are synth instruction-selection — loom emits the ideal i32.const 8; i32.shl and i32.lt_s; select.

Beat-LLVM (whole-program leverage)

loom sees the closed-world fused module + already runs a Z3 validator. It could forward proof-carrying facts (operand ranges, shift<32, select totality) as side-band metadata so synth folds/branchless-lowers with a proof, and specialize on the closed call set (e.g. drop the u16 mask/clamp bound if all call sites pass in-range) — information an MCU LLVM build, compiling an externally-visible symbol, structurally cannot use.

Reproduce: loom optimize <gust_kernel.wasm> --passes inline then check gust_mix still contains the call.

[avrabe]

Fixed in PR #229 (v1.1.15). Root cause confirmed live + a minimal repro (11-insn, 2-site, size-in-[10,50) leaf was NOT inlined). Both halves landed:

• candidate predicate → if size < limit (the site-count budget governs; MULTI_CALL_SITE_LIMIT was dead exactly as you diagnosed). Z3 verify-or-revert stays the backstop.
• new default-on dce-functions CLI pass (eliminate_dead_functions, v1.1.11 element remap scrambles the function-pointer table — valid-but-wrong code, falcon SIL gate fails (0.13m → 593.8m) #196-safe) removes the orphan multi-site inlining leaves behind.

Regression test test_inline_multisite_small_leaf_228 + e2e (leaf inlines at both sites, orphan removed, validates). Merge-gated on CI. The secondary findings (redundant inline arg-copy + CF-fragile simplify_locals) are queued as the next feature-loop item — your multi-site fix multiplies that copy, so it's the highest-value follow-up.

[avrabe]

Released in v1.1.15 (PR #229 merged → tag pushed → release workflow running). Multi-site small leaves now inline (predicate governed by the site-count budget) and the new default-on dce-functions pass removes the orphans. Re-bench gust_mix on v1.1.15 when binaries land. Next: the secondary findings (inline arg-copy + CF-robust simplify_locals) as the next release.

[avrabe]

Re-benched gust_mix on loom v1.1.16 — confirmed fixed. Pipeline: loom optimize gust_kernel.wasm --passes inline → strip to {memory, gust_mix} → synth compile --target cortex-m3 --all-exports --relocatable, timed under qemu -icount (instr≈cycles on M3), correctness-gated bit-identical over [0,2047].

	old (no loom inline)	loom v1.1.16
inner gust_wasm_scout::mix	separate fn, bl-called	inlined + DCE'd (gone)
gust_mix stack frame	24 B	8 B (the #230 arg-forwarding)
dissolved .text	140 B	132 B
fn-only cycles/call	1.125 ticks	1.05 ticks
ratio vs LLVM	2.81×	2.63×

The multi-site (2 call sites: gust_mix + gust_poll) leaf now inlines and the dce-functions pass removed the orphan — both confirmed on the real full module (not the isolated test that misled the original analysis). Thanks for the fast turnaround.

The residual gap (2.63×) is now entirely synth-side arithmetic lowering — filed/tracked at pulseengine/synth#428 (6-reg leaf prologue, register-shift vs lsl #imm, materialized-bool clamps). From loom's side this is resolved; closing-worthy once the secondary simplify_locals CF-robustness (#228 tertiary) is judged in/out.

[avrabe]

Great — thanks for the silicon re-bench. The 8 B frame (24→8) is exactly the #230 arg-forwarding landing, and mix inlined + DCE'd via the v1.1.15 predicate fix + dce-functions. Both halves confirmed on the real module.

Ruling on the tertiary (simplify_locals CF-robustness): OUT for now.

• The arg-forwarding (v1.1.16 — inline argument forwarding (#228 secondary) #230) already removed the redundant inline arg-copy at the source, in control-flow callers too — which is the case that actually mattered here (the 8 B frame proves it).
• Your data shows the residual 2.63× is entirely synth-side (synth#428), not a loom-side copy. So there's no demonstrated loom payoff left to chase with (b).
• simplify_locals' bail-on-any-control-flow is a load-bearing soundness guard (an equivalence created before a branch can be invalidated on one path). Loosening it to per-block dataflow is a real change to a proof-first pass; the Z3 verify-or-revert would backstop correctness, but adding that complexity with no measured win is the wrong trade under conservative-over-fast.
• If a future case shows a CF-function copy that actually costs cortex-m3 cycles, I'll revisit (b) then, with that case as the fixture.

From loom's side #228 is resolved (predicate fix + whole-function DCE shipped v1.1.15; arg-forwarding shipped v1.1.16). Closing; the residual is tracked at synth#428. The broader proof-carrying-facts work (so synth can drop the materialized-bool/register-shift overhead with a proof) is the loom↔synth contract proposed in #231.