inline_functions reverts when the CALLER contains an imported-function call (by-body modeling has no body for imports) — v1.1.4

[avrabe]

Summary

On loom v1.1.4 (cc66f398, after #151), inline_functions now correctly inlines i64 callees (thanks!) — but it reverts the inline whenever the caller contains a call to an imported function. The by-body call modeling introduced in #151 has no body for an import, so verification of the surrounding inline fails and the whole inline is reverted.

This blocks the gale C↔Rust seam dissolution: z_impl_k_sem_give inlines gale_k_sem_give_decide but also calls 5 env:: kernel imports (k_spin_lock, z_unpend_first_thread, arch_thread_return_value_set, z_ready_thread, z_reschedule), so the inline is always reverted.

Reproduction — the import call is the trigger (not i64/u64)

Reverts — caller has an imported call + inlines an i64-returning local callee:

(module
  (import "env" "ext" (func $ext))
  (func $dec (param i32) (result i64) (i64.extend_i32_u (local.get 0)))
  (func $z (export "z") (param i32) (result i64)
    (call $ext)                       ;; <-- imported call in the caller
    (call $dec (local.get 0))))

loom optimize v1.wat --passes inline --stats
  (no effect: inline)
🔁 Verification Reverts:  inline_functions  1 reverted

Inlines fine — same i64 work, no imported call (even with u64 pack/unpack):

(module
  (func $dec (param i32 i32) (result i64)
    (i64.or (i64.extend_i32_u (local.get 0))
            (i64.shl (i64.extend_i32_u (local.get 1)) (i64.const 32))))
  (func $z (export "z") (param i32) (result i32)
    (local $r i64)
    (local.set $r (call $dec (local.get 0) (i32.const 5)))
    (i32.wrap_i64 (i64.shr_u (local.get $r) (i64.const 32)))))

Instructions: 15 → 23   ✅ Optimization complete!   (inlined, no revert)

Trivial i64 (add1) also inlines now. The differentiator is solely the imported call in the caller. Real case: merged.both.wasm (WAT in synth#167 gist) reverts identically.

Ask

Model an imported call as an opaque/uninterpreted effect (a fresh unconstrained result + a havoc of observable state) in the by-body verification, rather than requiring a body — so the inline of other functions in the same caller can still be proven and kept. Without this, the verified inliner can't optimize any function that calls into the host (i.e., essentially every kernel primitive), and the LTO-parity seam dissolution stays closed.

Environment

• loom v1.1.4 (cc66f398), --passes inline
• imported-call repro above; real case = merged.both.wasm

[avrabe]

Fixed in v1.1.5 (https://github.com/pulseengine/loom/releases/tag/v1.1.5, commit 95a5f982).

Your repro now inlines — the import call is preserved, the local callee is inlined and verified:

$ loom optimize v1.wat --passes inline --stats
Instructions: 5 → 7   ✅ Optimization complete!     # 0 reverts; call $dec gone, call $ext kept

Root cause was upstream of the verifier, not a missing import model. You were right that it triggered on the imported call — but the by-body verifier wasn't the problem. It was a function-index-space confusion in the inliner: Call(func_idx) uses the full WASM index space (imports 0..N, locals after), but the inliner indexed its local-only function table with that full index and built candidates from a full-indexed call map against a local-indexed size map. With an import present, the import's index (0) collided with local function 0 — so the inliner tried to inline the void import call itself, emitting a local.set to bind params with no argument on the stack. That malformed body is what the verifier rejected (Stack underflow in LocalSet), reverting the whole inline. The verifier was doing its job; the inliner was feeding it nonsense.

Fix: account for the import offset everywhere — exclude imported indices from candidates (no body to inline), and map full→local (func_idx - num_imported_funcs) when indexing the local table, leaving imported calls untouched. Regression test added.

For the real seam (merged.both.wasm, z_impl_k_sem_give + its 5 env:: imports): this was exactly the blocker, so it should inline now — please re-test and confirm. If anything still reverts, attach the --stats output and I'll dig in.