# MEP-42 Backend Survey: Summary and Recommendation

## §1 What is in this directory
This directory contains a per-backend evaluation for MEP-42:

- `01_llvm.md` LLVM 20.x
- `02_cranelift.md` Cranelift (Wasmtime)
- `03_qbe.md` QBE
- `04_mir.md` MIR (Vladimir Makarov)
- `05_libgccjit.md` libgccjit
- `06_copy_and_patch.md` copy-and-patch (CPython JIT)
- `07_dynasm.md` DynASM (LuaJIT)
- `08_golang_asm.md` golang-asm (already used by Mochi vm2jit)
- `09_mlir.md` MLIR
- `10_c_as_backend.md` C as a backend (Nim, V style)
- `11_tcc_chibicc.md` TCC, chibicc, Cuik (reference points)
- `12_wasmtime_aot.md` Wasmtime AOT
- `13_emitting_object_files.md` Direct object file emission
- `14_jit_libraries_survey.md` AsmJit, Xbyak, Keystone, Iced, etc.

## §2 Comparison table

| Backend | Compile speed | Code quality (vs C -O2) | x86_64 | AArch64 | RISC-V64 | Wasm | Host lang | License | Binary footprint | Cost from Go (cgo?) |
|---|---|---|---|---|---|---|---|---|---|---|
| **LLVM 20** | slow | 100% | yes | yes | yes | yes | C++ | Apache 2.0 + LLVM Exc. | 60-300 MB | cgo via tinygo go-llvm, or shell out to llc |
| **Cranelift** | fast | 60-70% | yes | yes | yes | (via Wasmtime) | Rust | Apache 2.0 + LLVM Exc. | 15-25 MB | cgo to Rust staticlib, or subprocess |
| **QBE** | very fast | 70% | yes | yes | yes | no | C | MIT | 500 KB | subprocess (text IR) |
| **MIR** | very fast | 50-60% | yes | yes | yes | no | C | MIT | 500 KB-1 MB | cgo |
| **libgccjit** | slow | 100%+ | yes | yes | yes | no | C | **GPL v3 + RLE** | 80-150 MB | cgo, **GPL contagion risk** |
| **copy-and-patch** | instant | 70-80% (no cross-op opt) | yes | yes | yes (via clang) | no | technique | unencumbered | KB-MB of stencils | clang at build time, none at runtime |
| **DynASM** | instant | 90%+ (you control everything) | yes | yes | community | no | Lua+C | MIT | KB | Lua at build time, cgo |
| **golang-asm** | instant | 50% (no regalloc) | yes | yes | yes (untested) | no | Go | BSD-3-Clause | 5-10 MB | **none (pure Go)** |
| **MLIR** | slow | 100% | yes | yes | yes | yes | C++ | Apache 2.0 + LLVM Exc. | 150-300 MB | cgo or shell out, big ramp |
| **C as target** | medium-slow | 100% | yes | yes | yes | yes (Emscripten) | technique | unencumbered | 0 (user's cc) | none |
| **TCC** | instant | 30% (no opts) | yes | yes | partial | no | C | LGPL | 500 KB | cgo to libtcc |
| **Wasmtime AOT** | fast | 70% (via Cranelift) | yes | yes | yes | yes | Rust | Apache 2.0 + LLVM Exc. | 70-100 MB | subprocess `wasmtime compile` |
| **Object file emit (own)** | n/a | n/a | n/a | n/a | n/a | n/a | n/a | n/a | n/a | pure Go writers, ~3-5k LOC |
| **AsmJit / Xbyak / Iced** | instant | varies | yes | yes (AsmJit) | no | no | C++/Rust | various | small | cgo |

Notes:
- "Code quality vs C -O2" is informal; numbers are author claims plus community benchmarks.
- Wasm column "yes (via X)" means the backend covers Wasm only by chaining through another tool.
- "RISC-V64" means RV64GC unless noted.

## §3 What MEP-42 actually needs
The four MEP-42 priority targets are x86_64, AArch64, RISC-V RV64GC, and Wasm. No single backend covers all four with stable production support and a Go-friendly integration story:
- LLVM and MLIR cover all four but are huge and need cgo (or shell out).
- Cranelift covers x86_64 + AArch64 + RISC-V; Wasm is "use Wasmtime."
- QBE and MIR cover the three CPUs; Wasm is gone.
- C-as-target covers everything (any C compiler the user has, plus Emscripten/wasi-sdk for Wasm) with zero new Mochi dependencies.
- Wasmtime AOT covers everything **by making Wasm the universal IR**: Mochi emits Wasm once, `wasmtime compile` lowers to native.

## §4 Recommendation

**Phase 1 (MEP-42 1.0, target Q3 2026): adopt two complementary backends.**

- **Primary AOT backend: C-as-target (per `10_c_as_backend.md`).** Mochi's compiler3 lowers IR to C, shells out to the user's `cc` (preferring `zig cc` for hassle-free cross-compilation). This is the only backend that requires zero new dependencies of Mochi itself, covers all four MEP-42 priority targets plus every embedded toolchain on Earth, and produces code as good as the user's C compiler. It also reuses Mochi's existing `runtime/tcc/` scaffolding for a fast dev-tier compile (libtcc for `mochi run`, GCC/Clang for `mochi build`).
- **Primary JIT backend: keep golang-asm (per `08_golang_asm.md`).** Mochi's existing `runtime/jit/vm2jit` already uses twitchyliquid64/golang-asm to JIT on x86_64 and arm64. It is pure Go, ships in `go build`, and is good enough for an interpreter-tier JIT. Extend it to RISC-V (the relocations exist; the lowering does not). For Wasm JIT, defer (browsers and Wasmtime handle that).

This pair gives Mochi: zero new external runtime deps, native binaries on every MEP-42 target, a working JIT on the same targets, and a clean upgrade path.

**Phase 2 (MEP-42 2.0, target 2027): add Wasmtime AOT plus a higher-quality native AOT.**

- **Wasm path: `compiler3/emit/wasm` (per `12_wasmtime_aot.md`).** A native Wasm emitter unlocks browsers, edge runtimes, and Wasmtime AOT for native binaries. This is the highest-leverage single feature beyond Phase 1.
- **Higher-quality native AOT: QBE (per `03_qbe.md`).** When users need better-than-C-quality binaries (small startup, no libc dependency, tighter code), shelling out to QBE gives us a 500 KB toolchain that covers x86_64+arm64+riscv64. QBE pairs with Mochi's "small and pleasant to hack on" aesthetic better than LLVM/MLIR.

**Phase 3 (deferred): LLVM as a heavyweight option.** If Mochi ever needs vectorization, profile-guided optimization, or LTO-quality output, layer in LLVM via `compiler3/emit/llvmir` emitting `.ll` text and shelling to `llc`. This avoids cgo on every Mochi build host while keeping the LLVM option available for users who install it.

**Explicitly rejected for Phase 1**:
- libgccjit (GPL contagion).
- MLIR (massive overkill until Mochi grows tensor/GPU support).
- Cranelift in-process (cgo to Rust is too much friction; reach Cranelift transitively via Wasmtime AOT instead).
- DynASM (Lua build dependency, no RISC-V).
- TCC/chibicc/Cuik as the main native backend (too immature or too narrow).

## §5 One-line takeaway
**Phase 1 = C-as-target for AOT + golang-asm for JIT. Phase 2 = add Wasm emit and QBE.** This sequence preserves Mochi's "pure Go, no native deps at build time" identity, gives users native binaries on every MEP-42 priority platform via standard system toolchains, and leaves a clean upgrade path to higher-quality backends when needed.