docs(w54): investigation — gap is post-fold loop overhead, not missing fold

[chaploud]

Summary

The original W54 framing assumed zwasm was missing the constant-divisor fold that cranelift uses (multiply-high reciprocal). That assumption was wrong: both ARM64 (src/jit.zig:3582-3666 tryEmitDivByConstU32) and x86_64 (src/x86.zig) already implement the Hacker's Delight 10-9 magic-multiply, and dumping the JIT for bench/wasm/tgo_string_ops.wasm confirms three identical MOVZ + MOVK + UMULL + LSR sequences for the three i32.div_u 10 sites — zero UDIV instructions.

This PR captures that diagnosis so the next implementation pass can start clean from a verified hypothesis.

What the 2.1× gap actually is

1. Magic-constant load is re-emitted every iteration (~6 ARM64 instructions/iter for three div sites in tgo_strops). Cranelift's SSA + GVN hoist; zwasm's single-pass cannot without a preheader pass.
2. TinyGo's local.set → mov rd = rs1 stays in the JIT'd code where cranelift collapses it into a register rename via SSA.

Single-pass-compatible levers

1. Loop-preheader magic hoist — extend emitLoopPreHeader (today SIMD-only, src/jit.zig:4604) to scan for OP_CONST32 K → OP_DIV_U, allocate a callee-saved register (the prologue already spills x19–x28 unconditionally; functions with ≤13 vregs have x21 free without prologue surgery), pre-load the magic. tryEmitDivByConstU32 short-circuits when the magic is already live. Saves ~6 instructions per iteration on tgo_strops.
2. OP_CONST32 reuse across loop back-edges — saves the 1-instr const itself but not the magic that hangs off it. Skip unless (1) lands.
3. OP_MOV coalescing in linear-scan regalloc — substantial surgery; deserves its own W## entry.

Out of scope (would break single-pass): SSA + dataflow, global regalloc, auto unroll / vectorise.

Why no implementation in this PR

The hoist is well-bounded but invasive enough that it warrants a focused PR rather than a tail-end commit on a long autonomous run. Edge cases that need design-level attention before the first commit:

• Multiple different magic constants in the same loop body (which one to hoist? all? only the most-used?).
• Functions with reg_count ≥ 14 (the obvious x21 slot is occupied; need to either skip the optimisation or pick a caller-saved register and verify the loop has no calls).
• Nested loops (innermost wins? all levels?).
• x86_64 has a different register layout and a different cost ratio for magic loads — equivalent optimisation will need its own audit.

Test plan

• Doc-only PR; CI exists to verify no other gate trips.
• memo / checklist / roadmap rewordings cross-checked against .dev/w54-investigation.md.