fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: recover ISL conditions by CFG dataflow instead of a linear walk

Browse Source 
The linear walk's 10% unknown was a floor imposed by the method: a block entered only
by a branch has a well-defined state, just not one a straight-line pass can see.
tools/re-capture/isl_cfg.py replaces it with a worklist fixpoint that joins each
block's state over its ACTUAL predecessors -- a value survives only if every
predecessor agrees.

Over all 28 stages:
  instructions reached by the CFG          85.0%
  condition sites, unknown LHS             756 (10.00%) -> 402 (5.32%)
  of those, never reached at all           389
  joined away (predecessors disagree)       13
  both resolve but DISAGREE                161   <- linear walk was wrong here

Those 161 are on top of the 889 the previous jmp fix caught.

Two zero-results on the way, both my own bug, both caught because the number looked
wrong rather than because a test failed:

  * The first CFG run reached only 36% of instructions and made things WORSE (35%
    unknown).  Cause: the phase bases reach almost nothing.  Most routines are
    COROUTINES the engine starts from its trigger queue, with no static predecessor,
    so every start_coroutine target has to be seeded as an entry.
  * That seeding then found ZERO entries in a file with 216 start_coroutine calls,
    because the target is staged in TWO steps -- special[0] = imm, then
    local[0] = special[0] -- and I matched only the direct-immediate form.

Reachability went 36% -> 64% -> 85% as each was fixed.

The 389 still unreached are an honest limit rather than a gap: nothing in the bytecode
starts them; they are entered from the trigger queue at phase+272, by data rather than
code, so no purely static analysis reaches them.

isl_report.py conditions now uses isl_cfg; calls and phase-ends regenerate
byte-identical.  Stage 02 unknowns drop from 71 to 25.
This commit is contained in:
Sylpheed RE agent
2026-08-27 06:02:37 +00:00
parent 58b404aef4
commit 5ea9e38b35
5 changed files with 371 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/re/BACKLOG.md
View File

@@ -1442,9 +1442,18 @@ premise was wrong.**
on `builtin80`, which returns only 1 or 0. A/B over 28 stages: **889 of 7563
sites (11.75 %) change**, and unresolved goes **34 (0.45 %) → 756 (10.00 %)**.
The earlier "0.0 % unresolved" was a MISSING CHECK, not a strong result.
🟡 Recovering the 756 needs a real dataflow **join over each block's actual
predecessors** (a CFG fixpoint) — the branch targets are all known, the analysis
is not written. ▶️ **Still open:** the 35 unnamed built-ins (`builtin16` 132
~~🟡 Recovering the 756 needs a real dataflow join over each block's actual
predecessors (a CFG fixpoint) — the analysis is not written.~~
✅ **(2026-08-27) WRITTEN — `tools/re-capture/isl_cfg.py`.** Worklist fixpoint,
join over actual predecessors. **85.0 %** of instructions reached; unknown LHS
**756 (10.00 %) → 402 (5.32 %)**, of which **389 are never reached** and only
**13** are genuine join-aways. It also found **161 more sites where the linear
walk gave a confident WRONG answer**. ⚠️ Two of my own zero-results on the way:
the phase bases reach only 36 % (most routines are coroutines with no static
predecessor, so every `start_coroutine` target must be seeded), and that seeding
first found **0 entries in a file with 216** because the target is staged in TWO
steps (`special[0]=imm` then `local[0]=special[0]`). 🟡 The 389 are a real limit:
they are started from the **trigger queue at `phase+272`** — by data, not code. ▶️ **Still open:** the 35 unnamed built-ins (`builtin16` 132
sites, `builtin105` 117, `builtin103` 115 — each now a vtable-slot lookup);
✅ **(2026-08-27) partial — [structures/isl-unit-args](structures/isl-unit-args.md):**
reading the implementations shows **55** built-ins take a unit at `local[4]`,