simd_runtime: CpuOps DTO (third dispatch pattern) + GCC-scraped CPU table

[AdaWorldAPI]

Summary

Two scoped-together additions, both driven by the same insight — using scraped CPU metadata to drive runtime dispatch.

Piece A — matrix doc § M (GCC-grounded aarch64 enumeration)

The matrix doc had three aarch64 columns (A53 / A72 / A76) covering dispatch tiers but no per-core authoritative source. § M now records the canonical core list scraped from GCC's gcc/config/aarch64/aarch64-cores.def — 28 cores spanning V8.0-A through V9.2-A, each with its verbatim FEATURE_STRING.

Bug fix as a side effect: the A76 column legend claimed "+bf16" — but A76 is V8.2-A; BF16 came in V8.6-A. Removed the wrong claim; Apple M1 listed under A76 tier (V8.5-A baseline includes V8.2's dotprod+fp16 but NOT bf16/i8mm).

New tier groupings that should become matrix columns in Phase 3b (when NEON BFMMLA / BFDOT / FMLA.8h asm-byte arms land):

• V8.6+/V9 with bf16+i8mm: Apple M2+, Oryon-1 (Snapdragon X), Cortex-A510+, Neoverse-N2/V2, Grace, Ampere1+
• V8.4-A SVE outlier: Neoverse-V1 (Graviton 3)

Piece B — CpuOps DTO (the third dispatch pattern)

Adds src/simd_runtime/cpu_ops.rs exposing a third dispatch pattern that coexists with the existing two:

Pattern	Cost model	Wins when
1. crate::simd::* compile-time #[cfg(target_feature)] cascade	Direct monomorphized call, no runtime branch	Bench / fixed-target builds
2. crate::simd_runtime::vnni_dot_u8_i8 etc. — per-op LazyLock<fn ptr>	One CPUID + atomic-load per op, first call	Sparse-op consumers
3. cpu_ops() → &'static CpuOps DTO (THIS PR)	ONE CPUID at startup; every op is fn-ptr field	Dense-op consumers (linear-algebra pipelines)

The OpenBLAS / MKL dispatch model. All three coexist; consumers pick by import path:

// Pattern 1
crate::simd_ops::add_mul_f32(acc, a, b);

// Pattern 2 (per-op LazyLock — PR #185)
crate::simd_runtime::add_mul_f32(acc, a, b);

// Pattern 3 (this PR — one LazyLock total)
let ops = crate::simd_runtime::cpu_ops();
unsafe { (ops.add_mul_f32)(acc, a, b); }

Six static CpuOps instances baked at compile time, one per tier (amx_int8, avx512vnni, avx512f, avxvnni, avx2_fma, neon, scalar). Each references the existing trampolines in vnni_dot.rs / add_mul.rs — no kernel duplication; this module is pure dispatch glue.

The naughty data-driven part

cpu_ops_for_cpu(name: &str) -> Option<&'static CpuOps> — maps GCC CPU codenames to the dispatch tier they land in. Source: § M's GCC scrape. Spot-checks all verified by the test suite:

Pattern	CPUs	Tier
AMX-INT8 hosts	sapphirerapids, graniterapids, emeraldrapids	amx_int8
AVX-512 + VNNI	cascadelake, cooperlake, icelake-*, tigerlake, rocketlake, znver4, znver5	avx512vnni
AVX-VNNI no AVX-512	alderlake, raptorlake, meteorlake, arrowlake, arrowlake-s, lunarlake, pantherlake, sierraforest	avxvnni
Plain AVX2+FMA	haswell, broadwell, skylake, znver1-3	avx2_fma
All aarch64	apple-m1..m4, oryon-1, cortex-a76..a725, cortex-x1..x925, neoverse-n1..v3, grace, ampere1..1b	neon

Returns None for unknown CPUs.

Use cases: "what would this CPU pick?" introspection without running on it; cross-compilation reports; deployment-planning tools; integration tests asserting tier selection for named targets; explicit-tier-pinning ("force AVX2 to measure overhead").

Future: code-gen the table from a build.rs that fetches GCC's latest core list. Today it's hand-rolled from the scrape.

Test plan

• cargo test --lib --features runtime-dispatch: 2147 tests pass (was 2105, +5 new cpu_ops tests).
• 5 new cpu_ops tests:
  • cpu_ops_resolves_on_this_host
  • cpu_ops_stable_across_calls (LazyLock fires once)
  • cpu_ops_for_tier_known_names
  • cpu_ops_for_cpu_data_driven_lookup (spot-checks the GCC scrape)
  • cpu_ops_call_through_dto (full indirect-call exercise via (ops.vnni_dot_u8_i8)(a, b) and (ops.add_mul_f32)(...))
• cargo clippy --lib --tests --features rayon,native,runtime-dispatch -- -D warnings clean.
• cargo fmt --all --check clean.
• Default build (no feature) unchanged — zero impact on existing paths.

Backward-compat

The pub(super) wrappers in vnni_dot.rs and add_mul.rs (*_safe / *_safe_wrapper / *_scalar_wrapper) are new but purely additive — every existing public function in simd_runtime keeps its prior signature and dispatch behavior.

Out of scope (separate PRs)

• build.rs automation of the GCC scrape (today the data is hand-rolled).
• Extending CpuOps to cover the matmul / cast surfaces (today only vnni_dot_u8_i8, add_mul_f32, add_mul_f64 — the only surfaces with explicit per-tier kernels in simd_runtime/; the matmul/cast trampolines delegate to functions that runtime-dispatch internally, so they're a pub fn per-op call, not a CpuOps field).
• NEON tier expansion (neon_bf16 / neon_dotprod) — lands with the Phase 3b asm-byte arms.

https://claude.ai/code/session_01HbqooFZHAjaUtFEzhA1R2u

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d50caaf578

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve cpu-name lookup across target architectures

cpu_ops_for_cpu currently resolves a CPU name via cpu_to_tier and then immediately calls cpu_ops_for_tier, but cpu_ops_for_tier is #[cfg(target_arch)]-gated. On an x86_64 build, ARM tiers like "neon" are compiled out, so known names such as "apple-m2" map to None even though cpu_to_tier recognizes them. This breaks the documented “what would this CPU pick?” cross-target introspection use case and makes lookup results depend on the build host architecture rather than the CPU name input.

Useful? React with 👍 / 👎.