commit a4511b4fb8f7e0fe12062e90ab957e4e786894a4
parent 45d32e2eacd778102210685d5b180367f5894da9
Author: Ryan Sepassi <rsepassi@gmail.com>
Date: Wed, 10 Jun 2026 08:29:50 -0700
doc(TODO): record corrected memgrow + A.3 diagnoses
memgrow: the shared memory.grow lowering is correct (native passes); the C
backend's host allocates min_pages instead of max_pages — fix is in c_target
instantiation, not the lowering (adding realloc there would break native).
A.3: aa64/x64 lack the dedicated stage scratch regs rv64 has (their only
scratch doubles as mem-scratch; aa64 has no FP scratch), so matching rv64
needs a register-budget decision, not a localized edit.
Diffstat:
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/doc/plan/TODO.md b/doc/plan/TODO.md
@@ -53,10 +53,16 @@ Add new deferred fixes below as they are discovered.
- **c_target `memory.grow` backing-store bug.** `memory_grow_large/C` fails
(`expected 42 got 139`, SIGSEGV): a `(memory 1 300)` module grows to 300 pages
- then stores/loads at ~18.7 MB and segfaults — the C backend's `memory.grow`
- appears not to realloc the backing store to the grown page count. Pre-existing
- (confirmed failing identically at `de9bface`). Surfaces in `test-cbackend`'s
- wasm-front sub-suite. Needs a c_target wasm memory-model fix.
+ then stores/loads at ~18.7 MB and segfaults. Pre-existing (confirmed failing
+ identically at `de9bface`); surfaces in `test-cbackend`'s wasm-front sub-suite.
+ **Diagnosis (do NOT "add realloc to the lowering"):** the `memory.grow` lowering in
+ `lang/wasm/cg.c` is backend-shared and correct — the native lanes pass
+ `memory_grow_large`. It just bumps `memory.pages`; the backing store is allocated
+ by the *host/instantiation*, and native pre-allocates `max_pages` of linear memory
+ (so a store at page 299 is in-bounds) while the C-backend host evidently allocates
+ only the initial `min_pages`. The fix is in the C-backend wasm memory instantiation
+ (allocate `max_pages`, matching native), not the shared lowering — adding a realloc
+ there would wrongly perturb the native path.
- **aa64/x64 inline-asm operand-staging gap (A.3).** A register-constrained asm
operand that regalloc could not keep in a hard register (e.g. an address-taken
@@ -70,7 +76,14 @@ Add new deferred fixes below as they are discovered.
panics). rv64's extra staging branch is correct (it has dedicated stage regs
`RV_TMP2/3`+`RV_FTMP0/1`). Fix aa64/x64 to match, with test cases — this changes
which programs compile vs panic, so it must be a reviewed change, NOT folded into
- a dedup. Unblocks A.2 (below).
+ a dedup. Unblocks A.2 (below). **Blocker (register budget):** the gap is not a
+ localized edit — rv64 has *dedicated* stage regs separate from its mem-scratch,
+ but aa64 has only `AA_TMP0/1` (x16/x17, int, which double as the `"m"` mem-scratch)
+ and *no* FP scratch, and x64 likewise has only `R10/R11` + `XMM14/15` doubling as
+ mem-scratch. Matching rv64 means either permanently reserving more scratch regs on
+ aa64/x64 (a codegen-quality cost on every function) or collision-aware sharing of
+ the existing scratch between mem-staging and operand-staging — a register-policy
+ decision, hence "reviewed change."
## Deferred dedups & abstraction cleanups ("use the shared seam")
