phase9: extend trapping-arithmetic exclusion to the immediate ADDI form (worker B, verified)

Worker B found the exclusion detector's blind spot: opcode 0x08 (addi, traps
on overflow) appears in 7 of 1,666 worklist rows (frame adjustments
addi sp,sp,-28, loop counters) while 0 of 310 registered regions contains
one — the same disjointness signal as finding 26's R-type class. addiu (0x09)
is ubiquitous, so the 0x08 occurrences are the anomaly. Verified by the
coordinator from raw words: 7 rows, incl. 3 of partition A's 5 call-shape
rows (0x80011084, 0x800F3B10, 0x80010F30) and 0x800F3BB4 (previously
recorded as a separate coordinator negative — now explained by this class).
sf3_triage.trapping_arithmetic now counts opcode 0x08; worklist regenerated
(1,563 rows, excluded_trapping_arith=54). Synthetic test added.
P9-T5 route (a) widened: the immediate form is part of the class; the 7
ADDI rows are a ready-made minimal probe set for any cc1 candidate.
Also confirmed this cycle: the no-frame global-ra ISR family (ra saved to a
global, no stack frame — 0x801097A0 proved, 0x8010B420 pattern-transferred)
is a second library-asm class identical in kind to the CRT entry.

tools/sf3_triage

@@ -313,7 +313,7 @@ def bad_extent_start(start: int, end: int, payload: bytes) -> bool:
 
 
 def trapping_arithmetic(body: bytes) -> int:
-    """Count trapping `add`/`sub` instructions (funct 0x20/0x22) in a body.
+    """Count trapping `add`/`sub`/`addi` instructions in a body.
 
     Phase 8 measured that this class is disjoint from the matched corpus: 0 of the
     144 registered regions contains one, while 50 of the 1,937 `exact` extents do
@@ -321,12 +321,21 @@ def trapping_arithmetic(body: bytes) -> int:
     4.0-4.6 emit `addu`/`subu` for signed arithmetic and reject `-ftrapv`, so a
     body needing the trapping form cannot be reproduced with this toolchain at
     all: it is a compiler-class difference, not a source-shape problem.
+
+    Phase 9 widened the class to the immediate forms: opcode 0x08 (`addi`, which
+    traps on overflow) appears in 7 of 1,666 worklist rows (frame adjustments
+    `addi sp,sp,-28`, loop counters) while **0 of 310 registered regions**
+    contains one — same disjointness signal. `addiu` (0x09) is ubiquitous and
+    normal, so the 0x08 occurrences are the anomaly. The R-type forms counted
+    here are funct 0x20 (`add`) and 0x22 (`sub`).
     """
     count = 0
     for offset in range(0, len(body) - 3, 4):
         word = struct.unpack_from("<I", body, offset)[0]
         if (word >> 26) == 0 and (word & 0x3F) in (0x20, 0x22):
             count += 1
+        elif (word >> 26) == 0x08:  # addi (immediate, traps on overflow)
+            count += 1
     return count
 
 

tools/tests/test_sf3_triage.py

@@ -276,15 +276,20 @@ class WorklistTests(unittest.TestCase):
 
 
 class TrappingArithmeticTests(unittest.TestCase):
-    """A body needing trapping add/sub cannot be reproduced by any available compiler."""
+    """A body needing trapping add/sub (or addi) cannot be reproduced by any
+    available compiler."""
 
     def test_counts_trapping_forms_only(self) -> None:
         add = struct.pack("<I", 0x00000020)      # opcode 0, funct 0x20 = add
         sub = struct.pack("<I", 0x00000022)      # opcode 0, funct 0x22 = sub
         addu = struct.pack("<I", 0x00000021)
         subu = struct.pack("<I", 0x00000023)
+        addi = struct.pack("<I", 0x20A8FFFF)     # opcode 8 = addi (traps)
+        addiu = struct.pack("<I", 0x24A80001)    # opcode 9 = addiu (normal)
         self.assertEqual(sf3_triage.trapping_arithmetic(add + sub + addu + subu), 2)
         self.assertEqual(sf3_triage.trapping_arithmetic(addu + subu), 0)
+        self.assertEqual(sf3_triage.trapping_arithmetic(addi + addiu), 1)
+        self.assertEqual(sf3_triage.trapping_arithmetic(addiu), 0)
 
     def test_a_trapping_body_is_excluded_from_the_worklist(self) -> None:
         rows = _rows()