Faster match finding and decompression on Cortex-M7-class targets

[BrianPugh]

Stacked on #348 (uses its on-device harness for all measurements; retarget to main after that merges). Every change here benefits default library builds or documented compile-time knobs — nothing is benchmark-harness-specific.

Measured on STM32H7B0 @ 280 MHz (100 KB enwik8, window=10, byte-identical output in all configurations): the default build goes from 192.9 → 261.6 KB/s compression (1.36x) and 5.91 → 6.73 MB/s decompression (1.14x); the long-match repetitive workload's decompression improves 56%.

Changes

First-byte-prefilter match finder, default on ARMv7E-M (compressor_find_match_prefilter.c). On-device profiling showed find_best_match is 92% of compression time. The prefilter scans for the first input byte only — one 64-bit load + one zero-byte detect per 8 window positions — and verifies the 2-byte seed with a 16-bit load per hit. On in-order 32-bit cores this halves the SWAR work and live constants vs the desktop implementation (which spills heavily on 13 registers); it beats both the embedded baseline and the desktop implementation on both enwik8 and repetitive workloads. On out-of-order 64-bit hosts it is ~2x slower than the desktop implementation (which stays the 64-bit default), so it is gated to __ARM_ARCH_7EM__ + GCC + little-endian + unaligned, with TAMP_USE_EMBEDDED_MATCH=1 as the escape hatch and TAMP_USE_PREFILTER_MATCH=1 to opt in elsewhere.

Best-length gate in the prefilter and desktop match extenders: a candidate can only beat the current best match if it also agrees at offset *match_size, so a single byte compare rejects most candidates before extension. Provably output-identical; +5% on Cortex-M7, neutral within noise on x86_64/arm64.

Decompressor hot paths (tamp_window_copy no-wrap fast path; refill_bit_buffer on locals with a single writeback instead of repeated dereferences through aliasing-opaque pointers): +14% decompression on M7, +56% on the repetitive workload.

Reviewer judgment calls

• The prefilter gate covers Cortex-M4 (same __ARM_ARCH_7EM__), which I could not measure — the structural argument (fewer ops/byte, unaligned loads supported) says it wins there, but this branch's own history shows such reasoning mispredicting real silicon. Escape hatch exists; happy to narrow the gate if you'd rather wait for M4 data.
• The decompressor fast paths are gated off for __ARM_ARCH_6M__: they cost +150..500 bytes there (loop unrolling / register spills on the 8-register file) and their M0+ speed is unvalidated. armv6m binary sizes are byte-identical to before this PR (make binary-size checked). An RP2040 on-device A/B is a good follow-up.
• ESP32-C3 uses the generic copy macros, so its BENCHMARKS.md rows are likely stale-pessimistic after this PR; worth re-measuring when a board is at hand.

Measured but rejected

32-bit SWAR narrowing (0.93x on M7 — 6 positions per 2 loads amortizes worse than 14), __usub8/__sel SIMD32 (0.54x — GCC's GE-flag codegen serializes the loop), 16-byte loop unroll and 32-bit prefilter loop variants (both slower), ITCM code / DTCM window placement (<1% with I+D caches enabled — now documented as guidance in the device README instead).

Validation

• Full on-device suite passes in default, TAMP_USE_DESKTOP_MATCH, and TAMP_USE_EMBEDDED_MATCH configurations; compressed output remains byte-identical to the v1 reference in all of them.
• make c-test, make c-test-embedded, and uv run pytest (143 tests + 267 subtests, includes dataset regression through the Cython build) all pass.
• Host A/B benchmarks (arm64 + x86_64 via Rosetta): desktop implementation with the gate is neutral; host decompression neutral within noise.

🤖 Generated with Claude Code

[BrianPugh]

will break this up into a few cleanuped PRs once optimization is settled.