From f89e46ad886912980c93ff4478da0c46262e2c6e Mon Sep 17 00:00:00 2001 From: Christopher Williams Date: Thu, 24 Sep 2026 10:09:16 -0400 Subject: [PATCH] =?UTF-8?q?phase11:=20cookbook=20105-106=20=E2=80=94=20re-?= =?UTF-8?q?read=20granularity=20as=20a=20tunable;=20filter=20determines=20?= =?UTF-8?q?failure=20class?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 105: the pointer re-read granularity is a DIAL, measured in both directions by worker D -- re-read per store (700 B row, 46 times, matched), once per block (276 B row, matched), per statement (80 bytes too long), and never (does not match). Cause is aliasing. It is the same property as finding 45's named-locals family but as a COUNT rather than a yes/no. Plus: a genuinely uninitialised read in the original must be preserved, not corrected. 106: which failure class a row lands in depends on the FILTER, not the band. Worker D's cheap rows fail on frame/combiner/allocation/batch-shape and never on the branch diagnostics, so those belong on tie-break-dense rows. Route a diagnostic to the row shape it matches rather than broadcasting it. --- docs/MATCHING_COOKBOOK.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/docs/MATCHING_COOKBOOK.md b/docs/MATCHING_COOKBOOK.md index 97bad3e..2e1350c 100644 --- a/docs/MATCHING_COOKBOOK.md +++ b/docs/MATCHING_COOKBOOK.md @@ -1621,3 +1621,37 @@ log. **Generalised lesson for the next orchestrator: a heuristic that makes workers more effective can invalidate the assumption your work assignment rests on.** Adjacency optimised *which* row to take without anyone revisiting *who owns it*. + +### 105. The pointer re-read granularity is a TUNABLE, measured in BOTH directions (worker D) + +How often the source re-reads a sub-object pointer is a **per-site source choice** and it is +decisive in both directions. Worker D has now measured both ends of the range: + +| row | granularity | result | +|---|---|---| +| `0x8006BC74` (700 B) | re-read **before every store** — 46 times | matched | +| `0x800320D8` (276 B) | re-read **once per block** — one assignment per block | matched | +| same row, macro-style | re-read **per statement** | **356 vs 276 — 80 bytes too long** | +| same row, one read for the whole function | never re-reads | does not match | + +The cause is aliasing: each store through the pointer could write the pointer's own slot, so a +source that re-dereferences at every statement forces a fresh load. **This is the same property +as finding 45's named-locals family, but as a *count* rather than a yes/no** — so it is a dial +you can turn, not a rule to apply. + +**And a companion property worth preserving rather than "fixing":** `0x800320D8` leaves `v.b`/`v.c` +**uninitialised** on the single-word path and then subtracts them. **That uninitialised read is a +real property of the original, not a reconstruction error** — worker D recorded it in the file +header so nobody corrects it. `0x80079B34` reads `x[3]`/`y[3]` the same way. A worker who +"fixes" such a read loses the match. + +### 106. Which failure class a row lands in depends on the FILTER, not the band (worker D) + +Worker D's calibration: with the redundancy filter, its cheap rows fail on **frame/displacement +(59), combiner fold (63), allocation (45/82), and batch shape** — and **not once** on the four +branch/order diagnostics (100). + +So the branch diagnostics are the right tool for **tie-break-dense** rows (worker C's), and the +wrong tool for **repetitive** rows. **Route a diagnostic to the rows whose shape it matches, +rather than broadcasting it to everyone** — a correct lever applied to the wrong row class just +consumes attempts.