Worker A's 0x80033DC8 (360 B) and 0x8006A98C (132 B), plus two gp symbol rows
(D_80122724, D_80122728) that unblock 0x800A4CA8.
PROCESS DEFECT FOUND AND FIXED. Worker C and worker D both matched 0x800320D8
independently and D overwrote C's source file. Nothing corrupted -- both spellings match
and the region still reports 276/0/MATCH -- but one worker's effort was duplicated. The
partitions are genuinely disjoint (273/279/278/271, union 1101 = sum), so there was NO
assignment error: the gap was that no worker could know another had started a row, since
the registry only knows about MERGED claims and both started before either merged. The
root cause is the adjacency rule (cookbook 99, 4-for-4) crossing partition boundaries --
the best dispatch heuristic found so far invalidated the assumption the assignment rested on.
Fix: .run/p11/inflight.tsv (write-ahead log alongside the merge registry's commit log),
with the protocol written up in docs/ORCHESTRATOR_WORKFLOW.md so the next orchestrator
inherits it.
Worker A's 0x800556E8 and 0x80055654 (both first/second attempt).
Cookbook 99 is a DISPATCH rule, not a codegen one: take the row ADJACENT to one you just
matched. The binary is laid out by translation unit, so neighbours share the author's habits.
3 for 3, all first or second attempt, and it beat both the size ranker and the LRS ranker.
Cookbook 100 puts the three branch-shaped diagnostics side by side -- each maps a residual
shape to exactly one cause and each is a glance rather than a spelling:
branch displacement words only -> block NESTING (95)
first few instructions, right length -> then/else ORDER of a single-statement arm
whole prologue, same multiset -> declaration vs assignment order
Vector copies are now confirmed on FIVE independent rows.
Worker A's two adjacent claims (0x80036B14, 0x80036DA4).
Cookbook 95 is the cleanest diagnostic of the phase: a correct-length candidate whose residual
is a handful of BRANCH WORDS means the block NESTING is wrong, not the code inside the blocks.
Worker A got exactly 656 bytes (correct length) with exactly 2 differing bytes, both branch
displacements, by writing two guards as siblings instead of nested. Residual = 2 bytes at a
branch displacement => go look at your braces.
Also: the project's 4-int vector type is identifiable from the frame (multiple of 16 with
offsets stepping by 16); vector copies are struct assignments (third independent confirmation);
and an OPEN question is recorded -- 'the original spills everything, cc1 promotes' -- with a
request for a recipe from any worker who has solved it.
Worker B's four first-attempt claims (0x800B255C, 0x8004857C, 0x80030858, 0x800909D8).
Cookbook 94 is the strategic one: worker B's failures cluster into exactly TWO mechanical
classes -- reorg slot-fill choice and rare-epilogue fill -- and neither is a shape problem.
Both are the post-pass family, which two workers have now independently arrived at and
stopped on. That is the strongest argument yet for writing the post-pass rather than
grinding these rows with source spellings.
Worker B's 0x80069580 (88 B) and 0x8007E7FC (96 B), plus two gp symbol rows
(D_80122168, D_801221D0).
Cookbook 84 is the harness row for the post-pass: worker B isolated the rare-epilogue
transform exactly (move the frame release into the jump slot AND insert the load-delay nop
after lw ra), and established the load-bearing detail that as will NOT perform this fill
because doing so would put jr ra in the lw ra load-delay slot. So a post-pass that merely
moves the release into the slot produces wrong code. Also measured: maspsx=off is WORSE on
this row (72 bytes) because it strips nops from the beqz/jalr slots the original keeps, so
the two mechanisms are not substitutes.
85: cc1 folds SYM+N into a single la and SIX spellings do not defeat it.
86: cc1 cross-jumps identical guards; goto to a shared return label is the named lever.
Worker C's 0x800320D8 (276 B), matched on the FIRST spelling where its sibling 0x80031FC4
took 5 -- the family lever measured, on one family, both ways. Finding 55's limit confirmed
on the same family: a third row calling the same callee is NOT the same body and sits at
+16 instructions. The family transfers the derivation method and the stable positions,
never the body.
Also recorded: an OR nested inside an && chain is observable from the branch DIRECTIONS --
bne to the call block on one test and bnez to the manual-copy block on the other is
if (x == 0 && (a != 6 || b == 0)) call; else manual;
Worker D's 0x800910BC (280 B), its 8th match.
TWO CORRECTIONS TO THE COORDINATOR'S OWN COOKBOOK ENTRY, both from measurement:
- 67 was INCOMPLETE and cost worker D a spelling. The magic alone is AMBIGUOUS: D = 2^(32+s)/M
where s is the shift of the sra after the mfhi. 0x2AAAAAAB is /6 at s=0, /12 at s=1, /24 at
s=2, and worker D read it as /6 when the shift was 1. The corollary is worth having too: the
same magic twice in one function is not a contradiction (0x66666667 serves both /10 at s=2
and /5 at s=1, materialised once into a callee-saved register).
- The named-local rule is PER-SITE within one function. Naming a result the original consumes
immediately costs 2 words; naming one the original reuses is free. Apply the decision once
per VALUE, not once per function.
That is now the fourth correction to coordinator work this phase, and every one came from a
worker measuring something the coordinator had asserted.
Worker A built a repetitiveness score (repeated 2/3/4-instruction opcode subsequences,
normalised by body length) and produced the cleanest controlled comparison in the phase:
3 spellings on a 248 B repetitive row vs 9 failures on a 176 B tie-break-dense one. That
converts 'prefer a repetitive body' from a hunch into a sortable number, so size is
deprioritised as the ranking signal.
Also recorded: a transposed temp array is byte-required (int m[3][4] used as m[c][r]) with an
exact diagnostic -- right length + right instruction multiset + residual only on sp-relative
offsets means the frame LAYOUT is wrong, not the code; and when the original stores the same
slot twice, suspect two source statements rather than a scheduler quirk (GCC 2.7.2 has no DSE).
Worker C's 0x80031FC4 (276 B). Cookbook gains six entries, the most important of which is
worker C's correction of the COORDINATOR: a DEPENDENT row is one you cannot VERIFY, not one
you have MATCHED. C's 0x800A613C and 0x800FD120 had symbol rows outstanding, but
re-verifying against the tracked registry gave byte-identical results to the overlay runs --
both are still near-matches blocked on an ALLOCATION lever. Adding a symbol row unblocks the
verification, not the match; conflating the two would have had a worker stop working a row it
had not solved.
Also recorded: the address-taken value may be a PARAMETER not a local (frame 8 too big with
all offsets shifted by 8 is the tell); address-taken form forces a register; the struct
assignment is what BATCHES the loads where element stores serialise behind maspsx nops; and
the cop2 operand is the 25-bit field (0x486012 -> 0x4A486012).
+9 bodies: worker B's 0x8005E340, 0x8002C7EC, 0x800A8224, 0x8006B6BC, 0x80045F1C,
0x800F8A0C, 0x8002E9AC, 0x800196B4 and worker A's 0x800319F0 (whose dependent gp row
D_80122320 landed in the previous merge).
One new gp symbol row: D_801226E0 (append-only; the registry now has 395 rows).
Worker B's P1 band is finished: 10 rows, 5 matched, 4 near-matches with exact residuals,
1 blocked. THREE of the four near-misses failed on scheduling/allocation with the control
flow already EXACT, and one is a reorg slot-fill choice -- so that band's remaining yield
is in that class, not in shape work.
Two levers recorded from it:
- The address-taken value may be a PARAMETER, not a local. 0x80045F1C's frame is only 40
bytes yet it touches sp+56 and passes &a4 -- the FIFTH parameter, whose home is the
caller's outgoing-argument area at frame+16. Modelling it as a local reproduces the same
instruction SHAPE with a 48-byte frame and every offset +8 (22 differing bytes). So
'right shape, frame 8 too big, all offsets shifted by 8' => check for a parameter first.
- Address-taken form forces a register: 'int *p = &SYM;' gives la into a saved register
plus indirection, where reading the symbol directly gives the macro pair and no save.
+10 bodies in one gated pass from all three active workers: worker D's 0x8010AF50
(1232 B — the >800 B band broken on the FIRST attempt, in TWO spellings, 5.0x the old
244 B ceiling) and 0x80031BBC (260 B); worker C's 6 claims including the re-tested
0x800AFDBC which my nopmarker correction closed with NO source change; worker A's
0x8006B214 and 0x80027CA0.
Four gp symbol rows added (D_80122320, D_80121F2C, D_80122128, D_801226DC), APPEND-ONLY.
PROCESS BUG FOUND AND FIXED IN MY OWN FLOW: the merge chain piped the gate into grep and
chained with &&, which PROMOTED A DIFFED REGISTRY -- grep succeeds whenever it finds the
word 'result=' regardless of the verdict. Caught by the following make check (806734
differing bytes), reverted, and the registry restored from the last green commit. The
merge flow now lives in .run/p11/merge.sh, which gates on the gate's EXIT CODE and
refuses to promote on failure.
Worker D's recognition, which is worth more than the row: mult + mfhi + sra with NO mflo
is a CONSTANT DIVISION, not a 64-bit multiply. 0x4BDA12F7 is ceil(2^45/27648); a genuine
64-bit multiply emits mfhi AND mflo in every available cc1. Recover the divisor from the
magic as D = ceil(2^(32+s)/M), never from the constant's face value.
+5 bodies: worker A claims 5-8 (0x800507A0, 0x80017B50, 0x800BBAC8, 0x800AFACC) and
worker D's 0x8006BC74 (700 B). Every candidate gate MATCH before promotion; all md5s
verified on disk.
*** 700 B IS THE LARGEST BODY EVER MATCHED IN THIS PROJECT *** — 175 instructions,
2.9x the old 244 B ceiling, and the FIRST match in the 401-800 B band. It cost THREE
spellings, fewer than worker D's own 248 B row (four). Both residuals were mechanical:
a missing `li 4096 / sw` pair hidden inside a run of 46 zero stores ("a run of repeated
stores is not a run of identical stores -- read every immediate"), and four extra
pointer reloads fixed by naming the sub-object pointer ONCE for the three byte stores
of 255 while leaving the fourth store its own re-read (cookbook 45's named-locals
family at its cheapest). Nothing about 700 bytes was hard: the body is large but highly
REDUNDANT, and redundancy is what a matcher keys off.
NEW HARNESS MODE `maspsx=moves` (worker B's oracle result, developer-authorized).
Worker B ran all five SDK assemblers (ASPSX 2.56/2.67/2.79/2.81/2.86) and every
supported option as a read-only oracle and found that **ASPSX does NOT fill delay slots
at all** -- it produces maspsx's exact shape. So maspsx is FAITHFUL to ASPSX, and the
fills in the original did not come from ASPSX. That overturns the "model ASPSX's fill"
framing: what fills the slots is GNU `as` in REORDER mode, i.e. maspsx OFF, and the only
real gap is ONE MNEMONIC -- `as` expands cc1's `move` to `or` where ASPSX emits `addu`.
So the mode is `maspsx=off` plus a single `move`->`addu` rewrite, letting `as` fill
exactly the slots cc1 left empty while cc1's own `.set noreorder` windows are preserved.
DEMONSTRATED: 0x800FA5D8 now reports 132 bytes / differing_bytes=0 MATCH where default
maspsx gives 148 LENGTH-MISMATCH. 7 new tests; suite 246 -> 253.
REGRESSION-VERIFIED: make check green at 510 regions / 253 tests with the mode OFF, so
every one of the 510 regions is byte-identical. The mode stays opt-in per region --
worker B measured the counterexample 0x8002D2BC, which has the SAME cc1 shape but whose
original keeps the store before the jr with a nop, so the original's assembler behaves
differently in different files.
+8 bodies: worker A claims 1-4 (0x8005E820, 0x80012DE8, 0x8001644C, 0x800A6880)
and worker C claims 1-4 (0x80048180, 0x800B107C, 0x80082868, 0x80036134).
Candidate gate MATCH before promotion; all 8 md5s matched on disk.
FOUR gp symbol rows added for 0x80017C6C (D_80121A2C/34/3C/44), coordinator-verified
against the payload: the original materialises them with addiu $2,gp,244/252/260/268.
C's claim 4 (0x80036134, 248 B) is the SECOND body above the old ceiling, matched on
lever-c-large row 1 — so two independent workers have now matched above 244 B, and the
dispatch-artefact verdict is confirmed by result rather than by inference.
sf3_merge format fixes, both triggered by real worker files:
- a bare header row is now rejected with "looks like a column HEADER" instead of a
confusing "not a hex address: 'start'"
- a lone `-` in the override column means "no overrides", matching the absent-value
convention the other tracked tables use
Suite 246 tests OK; make check green: regions=502 AGREE, differing_bytes=0 MATCH.
Worker D's claim 0x8009F6A0..0x8009F798 (248 B) MATCHES. Verified independently by the
coordinator on a fresh work dir (candidate_bytes=248 differing_bytes=0 MATCH) and
gated on the whole binary before promotion. This is the FIRST body above 244 B ever
matched, and it sets a new corpus maximum (previous max 244 B at 0x80099078).
THE LEVER (worker D, 4 spellings): the local working buffer must be a 3x4 word array
(`int t[3][4]`, only columns 0..2 used), NOT `int t[9]`. The 4-WORD ROW STRIDE IS
BYTE-LOAD-BEARING: it moves the 2nd and 3rd triples to 0x10 and 0x20, makes the frame
48 B instead of 40 B, and leaves the unused 0x0C/0x1C slots the original shows. New
instance of cookbook 54 (a 2-D array's row stride is byte-load-bearing). The element
type is the other half: `short` locals let cc1 drop the sign extension (lhu/subu, no
frame); `int` locals keep it (lh/negu).
Diagnostic broadcast: correct length + right instruction multiset and order + residual
concentrated on the FRAME ADJUSTMENT and every sp-relative offset => suspect a local
aggregate's row stride / element size, not the control flow. D's variant (c) was a
textbook case: 19 differing bytes, all of them the frame size and the address shift
that follows from it, closed by one array-shape change.
Also in this commit — a fail-fast fix to sf3_merge. Worker D placed the source md5 in
the claim row's 4th column, which sf3_merge passed through as a region override, so the
row MERGED and only `sf3_match gate` failed later with "unknown override key 'md5'".
sf3_merge now validates override keys at merge time and rejects the row with a message
naming the valid keys and pointing at report.tsv for per-claim metadata. 4 new tests,
suite 242 -> 246, OK. The candidate gate caught it; the tracked registry was untouched.
+2 bodies (worker C2 claims 3-4). Candidate gate MATCH before promotion.
NEGATIVES EXTRACTION (the closing-checklist step that protects worker findings
from ignored staging being lost): imported 28 new negatives from all five workers'
staging into the tracked index, and dropped 28 rows that had since been REGISTERED
(the reconcile step working as designed). Index 166 -> 194 rows, address-ordered,
0 duplicates, 0 registered. Worklist 1193 rows; excluded_recorded_negative=170;
0 unregistered negatives survive into the worklist.
make check green: regions=493 AGREE, differing_bytes=0 MATCH, 237 tests OK.
Worker C2's cross-cutting finding recorded: three of its four negatives are the -O2
SCHEDULER, not source shape. For 0x800A6C34 (16 differing) and 0x80016F80 (45
differing), both at correct length, the identical source with
`cc1 -quiet -O2 -G0 -fno-schedule-insns` produces the original's instruction ORDER
byte-for-byte -- and both then show the same two-sided signature: sched OFF gives the
original's order but the wrong allocation (or the wrong delay slot), sched ON gives
the right allocation and the wrong order. Neither alone matches. C2 correctly did NOT
take the scheduler override (out of scope); both stay recorded as negatives with the
lever named. Diagnostic broadcast: correct length + a residual that is a permutation
of a few instructions + the unscheduled build matching the original order => the
residual is sched.
Also recorded: the commutative-operand lever has a COUPLED ALLOCATION side-effect
(0x80027744 at 4 bytes, 0x80050674 at 1 byte) -- every spelling giving the original's
addu operand order also flips which value takes v0 vs v1.
+2 bodies (worker C2 claims 1-2: 0x80051864 88 B, 0x8006AA10 120 B). Candidate
gate MATCH before promotion. make check green: regions=491 AGREE,
differing_bytes=0 MATCH, 237 tests OK.
C2 also confirmed the paired named-boolean rule exactly as broadcast (one shared
li a3,1 across four acceptance paths; nested ifs give two blocks and 124 B
LENGTH-MISMATCH; the single combined condition is byte-identical), and caught the
mask 0x00400000 vs 0x40000000 by computing the lui high half.
CROSS-CUTTING FINDING (worker C2, recorded for the cookbook): THREE of C2's four
negatives are the -O2 SCHEDULER, not source shape. Diagnostic: when the length is
exactly right and the residual is a permutation of a few instructions whose
-fno-schedule-insns build matches the original, stop hunting for a source shape.
Trap: on 0x80016F80 sched OFF gives the original's ORDER but the wrong allocation
while sched ON gives the right allocation and the wrong order, so neither alone
matches. C2 correctly did NOT take the scheduler override; all three stay recorded
as negatives with the lever named.
Also: the commutative-operand lever has a COUPLED ALLOCATION side-effect
(0x80027744, 0x80050674) -- every spelling giving the original's addu operand order
also flips which value takes v0 vs v1, because operand order changes pseudo creation
order. Finding 22's re-spell advice is necessary but not sufficient.
+6 bodies (worker A claims 23-26, worker B2 claims 8-9). Candidate gate MATCH
before every promotion.
FULL CLEAN AUDIT GREEN at the milestone:
make clean && make all exit 0
cmp exit 0
SHA-1 both files e173426c157384ebf1b6caf8c6fea18a85a14af9
registry 489 rows, 0 overlap, 0 unsorted, 0 bad extents,
0 missing sources, 480 distinct sources
firewall 0 tracked paths under any prohibited root (583 files)
suite 237 tests OK
The phase goal (475 from the 400 baseline) is met with 5 bodies to spare.
Per the plan, phase close requires the developer's explicit confirmation of the
milestone; this commit records the state, not the close.
SIZE-BAND FINDING now confirmed a third time, within-worker: worker B2's nine
matches cost 1, 4, 6, 4, 1, 2, 2, 1, 1 attempts -- the three <=120 B frameless leaves
all cost exactly ONE attempt, while the two >200 B P1 rows it opened with cost 6 and
4 attempts and produced ZERO matches.
Two more levers recorded from the closing rows:
- RECORD IDENTITY FROM WIDTHS (0x80041610): the two arms read three shorts at
+264/+266/+268 versus three ints at +20/+24/+28 through one extra indirection,
so they are TWO record types; declaring one shared type would have been wrong.
- a1[1] = -a1[1] RELOADS FROM MEMORY and its source order matters: the negation
reloads 4(a1) because the intervening store to 8(a1) may alias it.
- A 2-D ARRAY'S ROW STRIDE IS BYTE-LOAD-BEARING (0x800AC7A0): D[a3][a4] emits
sll a3,4 + sll a4,2 + add (correct length); D[a3*4 + a4] folds the outer *4 into
a second sll and comes out 4 bytes SHORT. When a scaled index is one sll short,
the source is a 2-D array, not a flattened index -- a LENGTH-class lever.
+3 bodies (worker B2 claims 5-7). Candidate gate MATCH before promotion; md5 drift
check clean on all three (second use of the guard). make check green: regions=483
AGREE, differing_bytes=0 MATCH.
Region option granted: gp=-D_80121BFC on 0x80048128. This one carries PER-ACCESS
evidence in a single merge: D_80121BFC is read gp-RELATIVELY in worker B2's claim 7
row (lw v1,708(gp)) and ABSOLUTELY in claim 5's row (lui v1,0x8012 + lw v1,7164(v1)).
So the same symbol needs the override in one region and not in the other -- direct
confirmation of worker B's lever 12 that the access form is per-SITE, and an argument
that the override is a region property rather than a symbol property.
THREE NEW LEVERS (worker B2), each with a control:
1. A LOCAL SHARED BY TWO GUARD BLOCKS GETS COALESCED; TWO BRACE-SCOPED LOCALS DO NOT.
0x8008BA80: the original's first guard loads the state byte into a0 (the
parameter's own dead register) while the second guard loads *a2 into a FRESH v1.
One function-scope local makes cc1 coalesce the live ranges into a0 and DIFFs;
brace-scoping each reproduces it. A SCOPING lever, distinct from the
named-locals family.
2. THE EVALUATION ORDER OF TWO SCALED TERMS IS BYTE-REQUIRED. 0x800504E4:
base + a0*384 + a1*3072 scales a0 first; base + a1*3072 + a0*384 scales a1 first,
which is the original. Worker B's claim-1 lever extended from the operands of one
'+' to the ORDER OF TWO INDEX COMPUTATIONS.
3. AN UNSIGNED LOOP COUNTER SHOWS AS sltiu vs slti -- ONE BYTE (opcode 0x0b vs 0x0a).
0x800504E4's i < 16 is sltiu, so the counter is unsigned int. The loop-test form of
the signedness trap.
Also independently reproduced: worker C's lever 6, (unsigned)(c - 58) < 2 giving ONE
addiu+sltiu pair where c >= 58 && c <= 59 gives two tests (on 0x80048128).
+3 bodies (worker B2 claims 2-4; claim 1 was already merged). Candidate gate MATCH
before promotion. make check green: regions=480 AGREE, differing_bytes=0 MATCH.
FIRST MERGE USING THE MD5 DRIFT GUARD (adopted after the 0x800A9C24 collision).
Worker B2's claim rows carry the source md5 and all three matched on disk at merge
time, so no re-verification was needed. B2 folded its gp=-D_80121B88 region option
into the claim row itself, which is the standing rule.
Region option granted: gp=-D_80121B88 on 0x800A6998. Byte-required and verified both
ways (with the override 128 B / 0 differing; without it 120 B LENGTH-MISMATCH).
Third instance of the per-site gp form. Worth recording that on THIS row BOTH the
symbol spelling and the literal spelling are wrong for two DIFFERENT reasons: the
symbol gives the gp-relative encoding the original does not use, and the literal
makes cc1 cache the address in s0 so the frame grows 24 -> 32 bytes with an extra
saved register.
TWO NEW LEVERS (worker B2):
1. A SHARED CALL PAIR HAS TO BE A NAMED goto LABEL. 0x800A6998 is an infinite loop
whose two func_800A6FAC(0) calls appear EXACTLY ONCE in the original, reached
both by fall-through and by the w != 0 branch. Only a source naming that block
reproduces it; while/for spellings either invert the loop (156 B) or make cc1
CROSS-JUMP the two ==0 tests so the x-load goes dead (124 B). Same goto
statement-form family as the 0x800A9C24 guard, but the lever here is SHARING ONE
BLOCK rather than branch polarity.
2. && KEEPS A BRANCH THAT EARLY RETURNS FOLD AWAY -- the exact INVERSE of the
named-boolean lever broadcast earlier. Three separate if (...) return 0;
statements make cc1 fold the third guard into a branchless boolean
(xor/sltiu, 124 B); ONE && chain with a single trailing return 0 keeps the branch
(byte-identical). A goto fail; ... fail: return 0; spelling is also identical, so
the distinguishing fact is "one combined condition with one trailing return".
PAIRED RULE: when the original has a BRANCH on a boolean expression, combine the
conditions into one && chain; when it has the BRANCHLESS form, name the boolean.
Also recorded: 0x800B67B8 is the CALLER of the registered func_80082750, and the
callee's source gave the D_80121C00 spelling directly (it holds a base POINTER, not
the table address), so the argument map transferred with zero guessing -- the
family lever working as advertised.
+4 bodies (worker A claims 19-22, all first-attempt). Candidate gate MATCH before
promotion. make check green: regions=477 AGREE, differing_bytes=0 MATCH.
THE STACK-SWITCH IDIOM IS NOW PROVEN TWICE, BYTE-EXACT, WITH NO OVERRIDE.
0x8006B9E0 matches on the first attempt with no maspsx override, no clobbers and no
operand declarations -- the three-macro form reproduces it exactly, including the
bare filler nop between the second restore and the epilogue's lw ra. Contrasting it
with A's 0x800BC658 near-match (same macros, off by 2 nops) isolates the variable:
0x8006B9E0's two calls have EMPTY delay slots while 0x800BC658's non-fast-path calls
set up an argument cc1 schedules into the slot. So the asm is not the variable -- an
ARGUMENT MOVE AT THE CALL SITE is. That narrows the 0x800BC658 remainder.
TWO NAMED-LOCAL FINDINGS, BOTH DIRECTIONS NOW OBSERVED (the family has seven
instances across the team):
- 0x8005E538: the HANDLE must be a named local loaded before the first call.
Inline, cc1 keeps only the object pointer in a callee-saved register and
RELOADS the handle after the first call (76 vs 88 bytes). Generalisation: a value
that must survive an intervening call has to be a named local.
- 0x800F66B8 is the MIRROR CASE and a useful NEGATIVE: d[0] and d[1] are each
loaded twice with neither held in a register, and the two loads of d[0] go to
DIFFERENT registers. Naming a local would have been WRONG. So naming a value can
be byte-required and NOT naming it can be byte-required; the diagnostic is the
load count, not a rule about locals.
Inline asm in src/func_8006B9E0.c is documented per the Phase 10 convention
(header states the observed sequence, the reason and the limits).
+8 bodies (worker A claims 11-18, all first-attempt; 16 of A's 18 claims needed
no override at all). Candidate gate MATCH before promotion.
TWO NEW LEVERS (worker A):
1. A two-arm selection's POLARITY is byte-required. For a1 = (x<2) ? a3 : saved,
the natural order and the ternary both emit beq v0,zero with the arms swapped
(right length, 5 differing bytes). Writing the larger-than arm first
(if (x >= 2) a1 = saved; else a1 = a3;) makes cc1 emit bne v0,zero with
a1 = a3 in the BRANCH DELAY SLOT, so that assignment runs on both paths and is
overwritten on the >=2 path -- which is the original exactly. Same family as the
mirrored comparison load order; second polarity case in A's partition.
2. A NAMED BOOLEAN LOCAL forces the branchless compare. rec[6] = ((a3 & 0xff) != 0) << 1
is branchy (92 vs 88); only naming the boolean first,
int flag = (a3 & 0xff) != 0; then rec[6] = flag << 1;
reproduces the original's andi / sltu / sll. Six spellings measured. cc1 will
un-do a boolean you inline when the VALUE (not the branch) is what you need.
make check green: regions=473 AGREE, differing_bytes=0 MATCH, 237 tests OK.
Worklist 1241 rows; excluded_already_registered=473.
+1 body (worker B2 claim 1, 0x8008A758, first attempt via the registered callee
func_80073F78). Candidate gate MATCH before promotion.
Worker C's cleanup-audit catch recorded: 0x800A6C34 (88B) is an OPEN near-match at
the correct length (16 differing bytes at 0x800A6C54) that fell out of C's staging
after a DIFF in its first batch. Added to the tracked negatives index. Coordinator
verified the residual exactly as C reported AND tested C's named lever (a) — the
gp=-D_80121B88 override does NOT close it (identical 16 bytes) — so the index
records the untried lever (a source order that stops the hoist) rather than the
disproven one. C's process note is recorded: run the cleanup audit BEFORE the final
report, not after.
make check green: regions=465 AGREE, differing_bytes=0 MATCH, 237 tests OK.
Worklist 1249 rows; index 166 rows, ordered, 0 registered.
+2 bodies (worker C claims 21-22; 19-20 were in the previous batch).
SIZE-BAND MEASUREMENT CONFIRMED (worker C, strongest evidence yet for the
size-first re-rank): after switching to the <=200B band, four consecutive rows cost
1, 1, 1 and 2 attempts, against 1-in-12 on the 200B-800B band. Same worker, same
levers, same day -- the only variable is the size band. The <=200B P2 band is where
the remaining bodies are.
make check green: regions=464 AGREE, differing_bytes=0 MATCH, 237 tests OK.
+2 bodies (worker C claims 19-20) and 3 gp symbol rows (D_80121F90,
D_8012196E, D_80121964). Candidate gate MATCH before promotion.
NEW EXCLUSION CLASS `restores_unsaved` (worker A, coordinator-verified). A body
that restores a callee-saved register it never saves cannot be a whole function:
the register it restores was established by an enclosing prologue that the derived
extent cut off. These are jal targets INSIDE a real function, so the walk began
mid-body — distinct from bad_extent_start, which flags starts that are not
function entries at all.
Verified disjoint from the matched corpus before acting, as the project requires:
0 of 462 registered regions trip the rule; 11 worklist rows do.
excluded_restores_unsaved=11; worklist 1265 -> 1253 rows. 5 new tests; suite
229 -> 237, OK. make check green: regions=462 AGREE, differing_bytes=0 MATCH.
Independent corroboration worth recording: the new rule re-derives 0x8010080C,
the false extent start worker C reported earlier via a completely different signal
(the first instruction reads a register the range never defines). Two independent
detections of one defect class. bad_extent_start is False for that row, confirming
C's observation that the older rule missed it. Its Makefile --exclude entry is
retained only as the provenance record for that defect.
+1 body (0x800C1424, worker C claim 18, closed with two register-allocation
levers: guard-on-the-expression so CSE keeps one load whose destination is the
guard's operand, and a counter initialisation as a statement so the counter
takes a2).
FORECAST FINDING (the important part of this commit): measured the matched
corpus against the remaining pool and re-ranked the lever files.
matched: 459 regions, median 48 bytes, 454 of 459 at <=200 bytes
remaining levered rows: median 456 bytes
Size is therefore the strongest predictor left, so .run/p10/lever*.tsv now ranks
size band FIRST and lever second:
P1 = <=200B and levered (47 rows across partitions)
P2 = <=200B, no lever (412) <- the unexploited band that actually matches
P3 = levered but >200B (503)
P4 = rest (303)
Worker C had proposed continuing on fresh P1 rows (old meaning: known-callee),
which under the new ranking are mostly P3 -- the 200-800B band where the
allocator/optimiser tie-breaks live. Redirected to P2 from the top.
Worker C's measured re-flag accepted (last 12 attempts produced 1 match, 8 of 9
sub-8-byte negatives being cc1 scheduling/allocation with no spelling lever) and
answered with a band change rather than a stop, since C is at 47% context.
+3 bodies from 447. Candidate gate MATCH before promotion.
Negatives reconciliation (the protocol step that protects worker findings from
being lost with ignored staging): imported 26 new negatives from all three
workers' staging into the tracked index. Index 140 -> 166 rows, address-ordered,
0 duplicates, 0 registered. excluded_recorded_negative 116 -> 142; worklist
1268 rows; 0 unregistered negatives survive into the worklist.
make check green: regions=459 disagreements=0 AGREE, c_regions=459
differing_bytes=0 MATCH, SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
+7 bodies from 440. Candidate gate MATCH before promotion on every batch.
SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9 stable; make check green
(regions=456 disagreements=0 AGREE, c_regions=456 differing_bytes=0 MATCH).
Note: my claims.with-options.tsv for worker B went stale (it predated claims
17-20) and the first attempt silently added 0 regions; regenerated from the
current claims.tsv and re-gated. Standing rule: regenerate the folded-options
claims file from the live claims.tsv immediately before every merge.
Worklist 1294 rows, excluded_already_registered=456 (= registry size).
Partitions refiltered: a=439 b=428 c=427, disjoint, union==worklist.
+8 bodies from 432 (440 total, from 400). All gated on the candidate whole-binary
before promotion. SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9 stable.
Registry option granted: gp=-D_801226F4 on 0x8002D364 (worker B). The first
candidate gate for this batch DIFFed (differing_bytes=1117197) because worker B
staged the option in a separate request file rather than in the claim row, so the
region merged without it; the tracked registry was never touched and the gate
caught it. Folded the option into the claim and re-gated to MATCH. Recorded as a
protocol event: a worker's region-option request must be folded into the claim
row before merging.
Evidence model: 0x8010080C is a FALSE EXTENT START (worker C, coordinator-verified
against the payload). Its first instruction is beq s0,zero and s0 is never written
in the range, so it is mid-body. The walk split one real 252-byte function
(0x801007E0..0x801008DC) at a spurious boundary because 0x8010080C is a jal target
from 0x8011419C. The row was unclaimable and is now a named exclusion
(excluded_named_exclusion 8 -> 9) with the reason in the Makefile and the
extents-defect record in the ledger. Fixing sf3_extents itself is left as a
bounded candidate, not attempted here.
Worklist 1304 rows, excluded_already_registered=446 (= registry size).
Partitions refiltered against it: a=441 b=432 c=431, disjoint, union==worklist.
32 new bodies from 400, all verified on the candidate whole-binary gate before
promotion. SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9 stable.
Registry requests granted (each byte-verified with a failing control):
cc1=-G8 on 0x800A6BEC; gp=-D_80121B88 on 0x80015D50
symbols D_80122700, D_80122704, D_80121AD4 (gp)
Harness: per-region maspsx modes wired through sf3_match (maspsx=noreordernop,
maspsx=regread) plus --no-jump-slot-nop/--nop-on-reg-read for range. Both are
opt-in and default-off; make check green at 441 with them off, suite 229 -> 232
tests. Carried as a TRACKED patch (tools/patches/maspsx-phase10-r1r2.patch)
because tools/maspsx/ is git-ignored, so an in-place edit would not survive a
fresh clone; patch verified to reproduce the working tree byte-identically.
R1/R2 are recorded as a MEASURED NEGATIVE: neither closes a region (cookbook
finding 40 has the mechanism and the remaining developer-owned route).
Docs: cookbook finding 40 (rare-epilogue mechanism + why the obvious maspsx fix
fails); SETUP.md maspsx patch provenance and apply step.
Negatives: 0x8010AA28 imported; index sorted by address (140 rows, 0 registered).
Full clean audit green: make clean && make all exit 0, cmp exit 0, both SHA-1
match, registry 441/0 overlaps/0 bad extents/0 missing sources, 0 firewall.
The 400-body target (P9-T6 checkpoint, 251 new bodies from 149) is crossed
on the coordinator's own whole-binary gate: c_regions=409, differing_bytes=0,
SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
Final batch: B's last 2 family members (0x800578EC, 0x800577E8, both 100B),
11 consecutive first-attempt family matches closing the run. Cycle-4 total:
47 new bodies from worker B following the milestone-close directive
(reliable-rows over exploration). The family-as-a-set lever (scan for rows
calling a matched target; stable positions selector->arg2 sentinel->arg3
a1->arg9, per-row elsewhere) drove 11 first-attempt closes.
Workers: B 60 claims (rotated cleanly, handoff block written with 104
report entries and the corrected cookbook items), C 70 claims (earlier
rotation). Coordinator holds merge/gate/ledger at 86% protecting the
essential role.
B 9-for-9 across the family batches. 0x80057B30 has TWO incoming stack
params; the family-set lever's scope limit sharpened: stable positions
(selector->arg2, sentinel->arg3, a1->arg9, extra->arg10) + per-row
positions elsewhere — the map proves once for the STANDARD form only, and
B corrected its own earlier 'map proves once' framing (belongs in the
cookbook with the lever). Two more 100-byte callers (0x800578EC,
0x800577E8) in flight for margin. Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
B: 42 new this cycle. Family rows restored the rate 3-for-3 first attempt
(selectors 6/17/15). Boundary note: 0x80057BE8 is in partition C (retired,
no race) — accepted under the standing verified-work-claimable policy. Key
finding: the family's argument map is NOT constant — stable positions
(narrowed a1 -> arg 9, 5th param -> arg 10) + per-row positions elsewhere
(no negu when there is no conditional selection — the discriminator
predicts it). Third selector-proving pair. Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
B: 39 new this cycle. Finding 5 at its sharpest: ONE byte (ori vs addiu)
was the whole difference — a literal vs symbol with identical address.
Three-way family now: lui-high-half, name-keyed-gp, literal-vs-symbol —
all encoding-only source constructs. 0x8003EB18 duplicated-arms mechanism
(cc1 shares something even with explicit duplication — 100 vs 108) and
0x80012834 tie-break recorded. Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
B: 38 new this cycle. 0x800AA01C three-way mode switch (if/else-if/else
chain — arms are exact complements: set bit 3/clear 6 vs set 6/clear 3 vs
clear both). Contrast finding: the move a0,v0 after the lookup decides
whether the flush gets the looked-up object or the original a0 — one
instruction, re-verified per family row (0x800AAC44 negative recorded).
Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
B's family-target scan paid off a 3rd time: 0x80057B84 = the family's 4th
member, matched on the 2nd attempt with two levers — (1) branch-vs-
branchless discriminator (how many distinct values are selected decides
the spelling), (2) the mask must be INLINED not held in a local (here the
repeated expression is correct and the local is the mistake — mirror
image of the usual named-locals lever). Two negatives recorded
(0x800179E0 guard polarity, 0x800C1E54 dead local). Gate MATCH whole-
binary SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
B 4-for-4 first attempt via the family-as-a-set lever (scan for rows
calling the same target after a match; the argument map is paid once).
Three siblings of 0x80057748 (selectors 11/4/16, some with the 5th
incoming arg as outgoing arg 10) plus 0x8006B66C (0x8006B1CC sibling with
a per-node flag test). Byte-identical-pair-teaching-constant-as-selector
(0x8005789C vs 0x80057C30 differ only in li a1,4 vs li a1,16). Gate MATCH
whole-binary SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
B: 32 new this cycle. Load-bearing insight: frame slots never read back are
the callee's 9th/10th stack arguments (0x80057748 was 68-vs-80 until the
10-arg call). Branchless conditional lever (ternary-zero differs from
if/else — sltu+negu+and). negu evidence set grows (3rd row) for finding
26's toolchain direction. Sibling 0x8005789C (11th stack arg) recorded
with the start-from-10-args note. Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
B: 30 new this cycle. 0x80103D0C matched; two source fixes recorded
(mask at use site; D_801220F4 is a short not int — sh vs sw tell).
Pre-screen correction: 50/55 (91%) of rare-epilogue rows in A are in the
mutual-exclusion blocked subset (move-pseudo detector fixed: rt==0 not
rs==0) — the class is not unmatchable but operationally mostly blocked;
coordinator's original skip instinct was partly right. New name-keyed-gp
finding: the gp marker hangs off the NAME not the address, so a
differently-named symbol with the right address silently loses gp-relative
form. Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
B solved one of C's parked picks with a better vehicle: the result-first
hypothesis needs RETURN-inside-loop, not a result local (a local allocates
to a0 and costs a move). 0x800263A8 matched 64B first try. Its twin
0x80016224 is now 8 differing bytes, a pure node-v1/payload-a0 register
swap — identical residual to B's own 0x800161E0 (one allocation family,
chartered together). Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
C's last claim 0x800A745C (flag-as-literal lever: named variable cost 4
bytes of s1 save/restore). Handoff accepted after a MEASURED stall signal:
1/4 batch, plus breaking two of its own recorded rules (gp+2300 arithmetic
and the g_/D_ name) in one batch — the criterion C committed to. Handoff
content: 71 claims all tracked-verified, 48 report rows, 38 parked
negatives by class, rareepi.py classifier (validated on 6 cases), orig.py,
lever list with scope limits, ~26 fresh rows in the 100-120 band.
Symbol note: D_80122234 already tracked (C's g_ request redundant — ignore);
g_801219D4 genuinely new for the open 0x80016E24. Gate MATCH whole-binary
SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
2 tier-2 rows (0x800B58C8, 0x80073364). C's weaker-batch honest report:
2/6 then +1 on a fix; new arithmetic instance (0x00FFFF00 from lui 0xff +
ori 0xff00 — the standing compute-don't-eyeball rule applied to two-piece
constant builds). Three genuine compiler residuals with untried levers
named. Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
4 tier-2 rows (0x80089B30, 0x800A9F7C, 0x800A34E8, 0x80103B8C). C tested
the register-binding lever on 0x800245D8 (FAILED, record corrected from
untried to tried-and-failed; family nuance kept for the pointer-based
0x8006AE04). New address-vs-value tell (same-looking global: lw rt,off(rt)
= VALUE, lui+addiu = ADDRESS). F10 re-confirmed (5th row). Gate MATCH
whole-binary SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
Worker B: 28 new this cycle. 0x800B6C14's inverted-polarity guard
(if (test() == 0) — nonzero skips the work) recorded as the 3rd
same-count-wrong-reading this cycle. Two pure-allocation negatives
(0x8007374C 7B reg swap, 0x800A86B4 pointer roles). Gate MATCH
whole-binary SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
5 tier-2 rows (0x80099024, 0x800B74D0, 0x80016DCC, 0x800282EC,
0x800474B0). C's repeat register-allocation signature flagged (0x800245D8
+ the 0x8006AE04 list-walk family share the same root: cc1 refuses an
argument register the original used; the register-binding lever is named
for both). Two confirmations: signed-width tell (3rd row: 0x80016DCC count
<=0 guard), and 0x800474B0's 3rd arg genuinely equals its 4th (faithfully
reproduced, not 'corrected'). Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
3 tier-2 rows (0x8008B910, 0x800AFB1C, 0x80028150), all first-verified.
C's no-arithmetic-errors batch confirms the python3 -c rule works. Three-row
list-walk family negative (0x8006AE04/0x8006AD5C/0x8006B470, all register
allocation) recorded with the untried register-binding lever
(register char *p __asm__("$4")). C's shape-based pre-grouping suggestion
for the phase's last stretch recorded. Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
Worker C diagnosed the earlier drop: the source was correct; the row failed
only because g_80121BFA (gp) was not yet tracked, so it resolved absolutely
(+8 bytes). Adding the symbol row first made it 80 bytes MATCH. C's standing
rule adopted: claims referencing symbols not yet in the tracked registry are
reported as DEPENDENT (symbol merged before the claim), never as verified
against a superset. Process error #2 (gp arithmetic) recorded. Gate MATCH
whole-binary SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
Worker B: 26 new this cycle, incl. the rare-epilogue three-way model
confirmed textually (sub-case b: 0x800F8928 mutual exclusion, before/after
68->64 then or-encoded moves), the discard-an-argument-outright pass-through
5th flavour, and D_80121ED8 corroboration. Worker C: 4 matched (0x80048E20,
0x8005784C, 0x800579A0, 0x80057AE0). GATE INCIDENT: C's 0x8002E3FC claimed
but its source is LENGTH-MISMATCH (88 vs expected) against the tracked
registry — dropped from the merge, reported back to C. Gate MATCH
whole-binary SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
4 tier-2 frames (0x8002864C, 0x80049298 with gp=-D_80121BFC, 0x801032D4,
0x800893E8). C's process-error owning (hardcoded ends instead of the
worklist column) and the F24 finding (caller-saved reloaded pointer across
a call means the store belongs before the call) recorded. Rare-epilogue
census: 47 tier-2 rows carry the pattern at their final instructions —
definitive class, broadcast to the workers. Gate MATCH whole-binary
SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
Worker C closed 0x80031F2C (a row the coordinator had recorded as a
negative) via the F23 struct-assignment lever (second confirmation) —
stale negative removed. Also 0x800129C8, 0x8009132C (F22: unsigned char
local re-masks an already-zero-extended lbu — width-of-DESTINATION tell).
C's link-error finding recorded: 'small-data section too large' on a
region that built fine = a duplicate gp symbol (name mismatch), not a -G
problem. New negative 0x80042E68 pairs with 0x80042DD4; named pointer
lever untried. Gate MATCH whole-binary SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9.
3 tier-2 frames from C (0x800A6840, 0x8002C728, 0x8002E968). Gate DIFF
avoided: C's 0x8002C728 used the name g_80121B84 which resolves implicitly
WITHOUT the gp marker (F19) — its local superset carried a g_-marked row so
C's own run matched, but the tracked registry only has D_80121B84. Fixed the
source to the tracked name; re-verified MATCH. C's 0x80025070 'negative'
corrected: that row is the coordinator's registered claim (stale index
entry removed). C's address-arithmetic charter warning (lui + negative
displacement must be hand-derived; five occurrences) recorded. Gate MATCH
whole-binary SHA-1 e173426c157384ebf1b6caf8c6fea18a85a14af9.
Christopher Williams