58b404aef4
Reading builtin80's body (0x82268460) to name it: it is NOT a predicate. It allocates a 20-byte object, stamps vtable 0x820A8CB0, magic 0xAB0311BA and the unit's live object into it, pushes it onto a queue via the same helper push.i uses, and returns 1 -- or 0 when the unit is absent. A command. That made the conditions listing impossible: it showed a six-way switch `if builtin80(TCT206) == 0 … == 5` on a function returning 1 or 0. Disassembling the site shows two unconditional `jmp`s between the call and the compare, so 0x1B6C0 is reached ONLY by a branch and its special[0] has nothing to do with builtin80. op12 is unconditional -- the next instruction is never reached by fall-through -- and the tracker walked through it exactly as it had walked through end_coroutine. Last iteration I fixed the instance and not the class, leaving 22x more bad sites in place than the fix removed. A/B over all 28 stages, 7563 sites, resetting at jmp as well: sites whose operands change 889 (11.75%) LHS unresolved, before -> after 34 (0.45%) -> 756 (10.00%) So the previous commit's headline "0.0% unresolved" was a MISSING CHECK, not a strong result: the linear walk always had some value to report, and reporting it was the bug. 10% is the honest figure and the other 90% is trustworthy for a reason. Also corrected: isl-unit-args.md illustrated its diff with 0x1B6C0, which is one of the bogus sites. The UNIT_ARG result itself stands -- it came from reading implementations, not from this listing -- but the example was picked from bad output. Not done, and said so: recovering the 756 needs a dataflow join over each block's actual predecessors, a CFG fixpoint rather than a linear pass. The branch targets are all known so the CFG is available; the analysis is not written. calls and phase-ends regenerate byte-identical; conditions changes on 187 lines.