feat(android): Add wasmi fallback for targets without cranelift support (arm32, browser-WASM)

[metavacua]

Summary

Building for arm-linux-androideabi (Android 32-bit ARM) is blocked by a hard limitation in the wasmtime dependency.

Root cause

larql-inference depends unconditionally on wasmtime with the cranelift feature:

# crates/larql-inference/Cargo.toml
wasmtime = { version = "29", default-features = false, features = ["cranelift", "runtime"] }

Cranelift (wasmtime's JIT compiler backend) has no 32-bit ARM backend. The build fails immediately at the cranelift-codegen build script:

error: failed to run custom build command for `cranelift-codegen v0.116.1`
thread 'main' panicked: error when identifying target: "no supported isa found for arch `arm`"

Cranelift supports: x86_64, aarch64, s390x, riscv64. It does not and has no plans to support arm (32-bit).

Required prerequisite (any path)

wasmtime must be made optional in larql-inference and excluded on 32-bit ARM. model-compute already does this with its wasm feature flag — the pattern exists:

[features]
wasm-experts = ["dep:wasmtime", "dep:wasmtime-wasi", "dep:anyhow"]

All call sites in larql-inference that use wasmtime would then need #[cfg(feature = "wasm-experts")] guards, with the WASM expert registry path degrading gracefully on unsupported targets.

Alternative runtime paths

Option A — wasmi (pure-Rust interpreter)

• wasmi is a fully interpreted WASM runtime with zero native-code generation — no Cranelift, no LLVM dependency
• Works on any architecture Rust targets, including arm-linux-androideabi
• Drop-in at the API level for the WASM expert registry use case
• Trade-off: slower execution (interpreted vs JIT), but for the expert dispatch path this may be acceptable
• Lowest complexity path to unblock the 32-bit Android build

Option B — wasmer + LLVM backend

• Wasmer supports multiple backends; its LLVM backend uses LLVM for code generation, and LLVM does have an ARMv7 target
• More complex: requires LLVM to be available and cross-compilable to arm-linux-androideabi
• More informative for the attention mechanism decomposition work in larql-inference — the LLVM IR for WASM expert modules exposes the full lowering of attention kernels, which can surface optimisation opportunities and structural problems not visible through Cranelift's opaque ISel
• Higher setup cost, but produces richer diagnostic output for mechanistic interpretability tooling

Recommendation

Start with Option A (wasmi) to unblock the build, keeping the WASM expert feature behind a flag. Option B (wasmer+LLVM) is a worthwhile follow-on if the attention decomposition analysis requires finer-grained IR visibility into expert execution.

Context

• aarch64-linux-android builds successfully (PR feat(android): enable aarch64-linux-android cross-compilation #94)
• Most Android devices shipping today are 64-bit; 32-bit ARM Android support is only needed for pre-2014 era devices (Cortex-A7/A9)
• 32-bit ARM is targeted due to its similarity to WASM sandbox environments which are on the way to in browser build + test + use.

[chrishayuk]

Thanks for the careful root-cause writeup — the cranelift-has-no-arm-ISA constraint is real, and the issue framing is correct that 32-bit ARM Android needs a non-cranelift WASM runtime path.

A few notes after going through #94 against this issue, now that the extractable bits have landed:

What was salvaged from #94

• feat(android): enable aarch64-linux-android cross-compilation #99 — aarch64-linux-android BLAS gating (cherry-picked, credits @metavacua)
• fix(larql-vindex): prevent overflow in lm_head vocab calculation on 32-bit hosts #100 — 32-bit usize overflow guard in lm_head vocab calc (the bug your armv7 attempt actually surfaced)
• chore(ci): add Dependabot config for GitHub Actions #101 — Dependabot config for GitHub Actions

These don't require any WASM-runtime decisions and stand on their own.

What's still open

The arm32 build is not fixed by what's been merged so far — #99 only handles BLAS, not the wasmtime/cranelift block this issue describes. So this issue stays accurately open.

Scope note for whoever picks this up

The recommendation in this issue is the right shape:

wasmtime must be made optional in larql-inference and excluded on 32-bit ARM

That's a cfg(target_arch = "arm") (or cfg(any(target_arch = "arm", target_family = "wasm")) if browser builds are also in play) fallback to wasmi — keeping wasmtime as the default backend on all 64-bit hosts. The fallback path needs:

1. [target.'cfg(...)'.dependencies] arms in larql-inference/Cargo.toml and model-compute/Cargo.toml selecting wasmtime vs wasmi
2. A thin adapter so the call sites (experts/loader.rs, experts/caller.rs, experts/registry.rs, model-compute/src/wasm/{runtime,session}.rs) compile against whichever backend
3. Critically: wasmi fuel metering requires Config::consume_fuel(true) before Store::set_fuel() is callable — I caught this in feat(android): enable aarch64-linux-android cross-compilation #94's implementation where Engine::default() was used and all 8 wasm_roundtrip tests failed with Engine("fuel metering is disabled"). Any future wasmi adapter needs that config or the WASM solver runtime is non-functional.

One pushback on the Option B framing

[wasmer+LLVM is] more informative for the attention mechanism decomposition work in larql-inference

The interpretability tooling in this repo operates on Rust + ndarray in the forward pass — it doesn't run attention inside WASM experts. WASM experts are a separate dispatch mechanism (the solver/expert registry, used for off-model ops like CP-SAT). The IR of a compiled WASM expert module isn't the IR of attention; it's the IR of whatever the expert author wrote, after already being wasm-as-IR. I wouldn't load-bear runtime choice on that argument.

What I'd suggest

Re-scope this issue's title to something like "Add wasmi fallback for targets without cranelift support (arm32, browser-WASM)" and treat it as the single ticket for the proper cfg-gated swap, separate from any compliance / licensing / workflow changes #94 also bundled.

[metavacua]

Hi @chrishayuk,
Glad the slight mishap on my part was useful.

The wasmi fuel issue was discovered independently during the course of my efforts to build and test the android versions.

That said, I have successful demonstrations of getting LARQL to build and test on QEMU android emulation on standard github runners with the wasmi change. Unfortunately, my bot broke the default wasmtime implementation in a way that I have difficulty evaluating for correctness, so I can't recommend my current build verbatim to the original, but I do want to report that I have had success in implementing some of the recommendations of this issue.

"separate from any compliance / licensing / workflow changes #94 also bundled."
Pardon the cruft; there's a bunch of reasons that I forked and work on the fork rather than directly on the original repository.

-Ian D.L.N. McLean

[chrishayuk]

@metavacua sweet was super useful... i cherry picked a bunch of stuff but if you want submit a fresh pr with anything else you think it's useful of this version, that would be awesome

[metavacua]

@chrishayuk I am pleased to present metavacua#52. There are some potential issues surfaced, but all crates--with the notable exception of LARQL-Python--build and test (with some test failures) on Android OSes under QEMU. aarch64 Android OS gets a rather significant amount of the way through the larql-vindex / test - android-aarch64 (pull_request) and timed out at 35 minutes.

kv-cache-benchmark / test · windows-latest (pull_request) is fixed in my main branch; the armv7 failures are due to certain hard coded test assumptions which are mildly informative but perhaps practically not interesting at this time.

I consider this a relatively definitive proof of concept that LARQL builds and runs on all operating systems, and critically, the workflows and results make relatively explicit the dependencies and premises involved in the proof tree of the composite program. It could be refined by more accurate emulation, and of course, actual building and testing on hardware.

QEMU Emulation Accuracy Trade-offs for Android

What QEMU gets right

Instruction set semantics: QEMU's TCG (Tiny Code Generator) translates guest instructions to host instructions with high fidelity for integer arithmetic, load/store, and control flow. For pure computation — which includes most of the attention forward pass — the results are numerically identical to hardware.

Memory model emulation: QEMU emulates the guest memory model but executes on the host memory model. On an x86_64 runner:

• x86 is TSO (Total Store Order) — stronger than required
• aarch64 is weakly ordered (requires explicit barriers)
• armv7 is also weakly ordered, but with different barrier semantics than aarch64

QEMU running aarch64 on x86_64 does not relax stores to match the aarch64 memory model — it over-approximates with TSO. This means:

• Correct programs run correctly
• Incorrectly synchronized programs may pass under QEMU but fail on real hardware
• The structural rules your attention implementation depends on for ordering may not be probed accurately

---

aarch64 specifically

Property	Real Hardware	QEMU on x86_64
Memory ordering	Weakly ordered, explicit barriers	TSO over-approximation
SIMD/NEON	Full SVE/NEON available	Depends on QEMU version and -cpu flag
Atomics	LSE (Large System Extensions) on ARMv8.1+	Emulated, may not expose LSE/non-LSE split
binfmt_misc execution	Native	Transparent via host kernel registration
Page size	4K or 64K depending on kernel config	Host page size, usually 4K

The LSE vs non-LSE atomic split is relevant: NDK r23+ prefers LSE atomics on aarch64. QEMU may or may not emulate the LSE instructions depending on the -cpu cortex-a53 vs -cpu max flag. If your CI doesn't set -cpu explicitly, you may be getting an inconsistent atomic instruction set.

---

armv7 specifically

Property	Real Hardware	QEMU on x86_64
Memory ordering	Weakly ordered, LDREX/STREX exclusives	TSO over-approximation
Thumb/Thumb-2	Native interworking	Emulated, generally accurate
NEON	Optional, varies by SoC	Present or absent based on -cpu flag
VFPv3	Common	Emulated
Kernel ABI	binfmt_misc dispatches to qemu-arm	Correct for syscall interface
32-bit address space	Hard 4GB limit	Enforced by guest address space

The armv7 emulation is more accurate relative to its target than aarch64 emulation is, paradoxically, because armv7 hardware is itself more uniform — there is less variance in the feature set that QEMU needs to emulate correctly.

---

The epistemic problem for the metavacua#52 CI matrix

The metavacua#52 CI is using QEMU to probe the target resource theory, but QEMU substitutes the host memory model for the guest memory model in the ordering dimension. This means:

What the CI matrix accurately captures:

• Instruction availability (does the ISA support this operation at all)
• ABI compatibility (calling conventions, struct layout, pointer size)
• Linker symbol resolution (the Category B failures you diagnosed)
• Syscall interface (the /data/local/tmp and linker64 failures)
• Compute correctness for sequentially consistent code

What the CI matrix does not accurately capture:

• Whether relaxed atomics in the attention implementation are correctly synchronized for the guest memory model
• Whether lock-free data structures are correct under the guest ordering rules
• Whether the fence instructions LLVM emits are sufficient for real hardware

quasi-proof-theoretic framing

QEMU is not a faithful functor from the target resource theory into the host execution environment. It is faithful on the multiplicative fragment (computation) but not on the exponential/modality fragment (sharing, synchronization, ordering).

The structural rules governing exchange are not correctly probed though we have evidence of some efficacy by the discovery of various non-determinism in certain operations on certain operating systems.