Repository navigation
perf: consecutive const-address stores re-materialize the linear-memory base every time #468
Description
Activity
[issue-hunt loop] Scoped — spike in PR #469 (no codegen change, frozen-safe).
Confirmed empirically + found the load-bearing result: the two codegen paths diverge, and the relocatable path already implements the target shape.
Base-materialization count (
movw ip,#<base_lo>), cortex-m4:fixture optimized (non-reloc) relocatable 7-store repro 7 (6 redundant) 0 flight_seam 21 0 flight_seam_flat 42 0 - Relocatable (
select_with_stack): base is a relocated symbol → pinned infponce, each store[fp,#off]. Already optimal. - Optimized (
optimizer_bridge.rs): base is an absolute constant → re-materialized intoip/r12 per store.ipis encoder scratch (can't persist across the indexed-load expansion), so the path has no persistent base register today.
⇒ fix is allocator-aware (reserve a callee-saved base reg + hoist
movw/movtonce per const-base store-run, mirroring the relocatable[base,#off]shape) — not a post-pass peephole. ~48 B + ~12 cyc on the 7-store fixture; scales with run length.Spike (PR #469) commits the generic fixture + the measurement/fix-shape note, frozen-safe. The byte-changing CSE (
SYNTH_BASE_CSEflag-off → differential → on-target gate → flip) is the separate next gated step.— issue-hunt loop (avrabe automation), not a maintainer decision.
- Relocatable (
- added 7 commits that reference this issue
on Jun 24, 2026 Verified fixed on v0.42.0: three consecutive
i32.store (i32.const …)on the direct/self-contained path now emit onemovw/movtbase materialization (2 instructions total), reused for all three stores — the re-materialization pattern this issue reported is gone (landed across the const-CSE #514/#516 + base-CSE #482 levers). Repro used: 3-store .wat,--cortex-m -t cortex-m3, objdump count. Closing; reopen with a .wat if a shape still re-materializes. (— autonomous issue-hunt/release loop, posting under the shared avrabe account.)- added a commit that references this issue
on Sep 15, 2026
Pattern
On the absolute / native-pointer store path,
i32.store* (i32.const ADDR) Vlowers to:The base is a loop-invariant compile-time constant, but it's re-materialized (
movw+movt= 8 B, ~2 cyc) before every store. A straight-line run of N stores pays N base-materializations where 1 would do. This is common in struct/field initializers (a function that sets up several adjacent fields).Repro (generic)
scripts/repro/redundant_base_materialization.wat— 7 consecutive const-address stores.Cost
~
(N-1) × 8 B+(N-1) × ~2 cycper straight-line store run. For a 7-store initializer that's ~48 B and ~12 cyc recoverable in one function; it scales linearly with field count, so field-heavy init code pays the most.Fix direction
Hoist the constant base into a stable register once per straight-line region (const-CSE of the base —
ip/R12 is encoder scratch and clobbered per-access, so the hoist target must be a preserved reg or the already-reserved memory-base register), then address each store asadd ip, base_reg, <addr>; str. Same const-CSE family as the existing redundant-const elimination, specialized to the 2-instruction MOVW/MOVT base.Byte-changing → would land flag-off (frozen-safe), execution-differential + on-target cycle gate, then default-on — the established lever path. Tracked under #390 / VCR-RA (epic #242).
Related
A DWARF
.debug_lineemitter already exists (--debug-line, shipped v0.12.0) for source-line stepping into generated code; richer variable-location info is the gated Tier-2 follow-on (VCR-DBG-001, blocked on the register allocator).