[mahaloz]

In serde-hkx 0.7.3's hkxc.exe, the 194 KB function 0x1406198f0 spends two thirds of its time in rule pools, and most of their 6,215 passes over it and its jump-table sub-pipelines change only two or three ops:

$ KUNA_ACTION_PROF=prof.txt kuna decompile-all hkxc.exe --addr 0x1406198f0 --json --jobs 1 --max-fn-seconds 0 > out.json
$ grep oppool1 prof.txt
  131779.7 ms   39.77%       4150 calls  jumptable/oppool1
   82568.0 ms   24.92%       2065 calls  decompile/oppool1

Side by side on two pinned cores of a busy machine, the whole function takes 437.0 s user on main and 342.6 s with this PR, with identical JSON.

The stack pointer's join at the function's shared exit block (0x1406490f3) has 626 to 674 inputs, each the COPY that the last call on that path left. RulePropagateCopy propagates one input per application, as upstream does, and a rule applies at most once per op per pass. So each analysis spends one pass per input, and 1,810 of those passes swept every op to make one propagation plus the removal of the COPY the pass before had freed.

• New option copywaves (default on), widening deadwaves. RulePropagateCopy now records the op it changed and the Varnodes it read before and after. A pass whose only changes were dead-op removals and such replacements is followed by a wave over their neighbourhood, and a replacement inside a wave widens the wave instead of ending it.
• A wave also offers an op it reaches only for its opcode (an op a sub-variable or split flow fires on) just those far-walking rules, until one applies. The other rules test only what lies next to the op, which the previous pass did not touch.

Tests: tests/stages/kuna-copywaves.xml (same C, live IR and op count with the option off and on) and unit test copy_waves_propagate_the_join_as_sweeps_do_and_visit_only_its_neighbourhood (same end state; the 30 passes after the first offer the unrelated ops nothing, and their far rule exactly as before). No datatest or stage expectation moved.

68,488 corpus functions (decbench O0/O2/O2-noinline, sqlite3.dll, _decimal.pyd, CrashLogger.dll, lua, luajit, libsqlite3, cross-arch lua/sqlite builds, APoseFix.dll, hkxc.exe's 48 and libpython3.11's 68 largest functions; --jobs 4 --option protoorder off) print identical records; the two that differ, tar -O2-noinline 0x10dd0 and sq_ppc32_O2 0x1007df90, are --jobs flakes that differ the same way between two builds of main.

Speed, 7 binaries (gzip -O0, grep, kmod, dash -O2-noinline, bzip2, liblua, CrashLogger.dll) on pinned cores of a busy machine, n=5: sum of per-binary min user 142.74 → 142.53 s, sum of medians 170.81 → 176.38 s (CrashLogger's median carries it; the other six 37.37 → 37.80 s).

Part of #1034.

🤖 Generated with Claude Code

https://claude.ai/code/session_0179iMKMUBscgGJBW9XHH5hJ

[mahaloz]

[AUTOMATED] Pushed 0909823 on top of fb11e25: a wave after a copy propagation now also offers the propagated value's definition and readers.

Repro (fails on fb11e25, passes on 0909823):

cd decompiler && cargo test -p kuna-decomp --lib -- infra::action::tests::copy_waves_offer_the_definition_of_the_propagated_value

note_wave_input_change ran before op_set_input and recorded the op, the inputs it read before the change and its output, but not the COPY input it reads afterwards (invn). When the COPY stays alive (it has other readers), the following wave therefore never offered invn's definition, whose output had just gained a reader, and the pool could converge with a rule on that definition still unfired (the test: a rule on an INT_ADD that tests its output's readers). Chapter 03 and the option summary already describe the wave as covering "every Varnode it read before and after"; the commit records invn as well.

Cost: rule tests on hkxc.exe 0x1406198f0 775,493,707 -> 775,508,535 (+0.002%), tar/grep/libsqlite3 +0.01%. Output is identical to fb11e25 on 50,709 functions (23 binaries: x86-64 ELF and PE, MIPS BE/LE, PPC32).