You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(simd_runtime): expose cpu_tier_for_cpu for cross-arch introspection (codex P2)
Codex flagged on PR #187 that `cpu_ops_for_cpu` is cfg-gated through
`cpu_ops_for_tier`, so cross-arch lookups silently return None — e.g.
`cpu_ops_for_cpu("apple-m2")` on an x86_64 build maps "apple-m2" → "neon"
via `cpu_to_tier`, but then `cpu_ops_for_tier("neon")` is compiled out
because `CPU_OPS_NEON` is `cfg(target_arch = "aarch64")`.
This broke the documented "what would this CPU pick?" introspection use
case, which is supposed to work for deployment-planning tools and
cross-target reports regardless of the build host.
Fix: promote the previously-private `cpu_to_tier` to `pub fn
cpu_tier_for_cpu`. It returns `Option<&'static str>` and is cfg-free,
so `cpu_tier_for_cpu("apple-m2")` reliably returns `Some("neon")` on
every build target.
`cpu_ops_for_cpu` keeps its current semantics (current-arch only) but
the docstring now explicitly says so and points cross-arch callers
at `cpu_tier_for_cpu`. Returning a phantom CpuOps with scalar fn ptrs
for cross-arch lookups would lie about behavior — better to return
None and force callers to use the honest tier-name surface.
Added regression test `cpu_tier_for_cpu_is_cross_arch` that asserts
the cross-arch CPU names resolve on every build host.
0 commit comments