test(cpu): stop the bf16 prefill guardrail asserting a route AVX-512 hosts cannot take

[justinchuby]

Fixes the Rust coverage failure in kernels::matmul::tests::half_prefill_gebp_agrees_with_the_blocked_half_gemm_and_is_the_route.

What the failure was

matmul.rs:5434: assertion `left == right` failed: BFloat16 m=2: prefill did not take the fused widen-pack GEBP
  left: 0   right: 1

This is a latent test defect, not a regression, and it is not attributable to any commit. A naive bisect says otherwise — Rust coverage (Linux x86_64) is green at eb8ce595 (#1604) and red at a429538f (#1608) — but #1608 changes exactly one file, crates/onnx-runtime-ep-cuda/src/provider.rs, and that coverage job's package list does not contain -p onnx-runtime-ep-cuda at all. The commit's only changed file is not compiled by the job that went red. The red tracks which runner picked up the job, not the code.

half_gemm_tile tries the native AVX-512 BF16 kernel before the GEBP and returns:

if format == HalfFormat::Bf16 && x86_bf16::native_available() {
    x86_bf16::gemm(a, b, c, m, k, n);
    return;                       // never reaches the GEBP route
}
if half_prefill_gebp_selected(format, m, k, n) && half_prefill_gebp_enabled() { ... }

On a host with avx512bf16 (Cooper Lake / Sapphire Rapids and later) a bf16 tile legitimately never reaches the GEBP and the counter stays 0. GitHub's Linux x64 pool is a mix of Intel generations, so the same commit passes or fails depending on the runner. The precedence is already encoded for decode in half_decode_prefers_gebp_when; only prefill's guardrail lacked it.

A second, latent hardware assumption in the same test

The test already had if !crate::backend::has_simd_x86() { continue; }. That is a continue, so on a non-AVX2/FMA host it skipped the numeric comparison against naive_matmul as well as the route assertion — deleting the half of the test that is valuable on every host. It has never fired (all current runners have AVX2), so it was latent, but it is the same class of bug.

What changed

The expectation is now derived from the predicates half_gemm_tile actually dispatches on, rather than restating hardware conditions in the test:

let expect_native_bf16 = format == HalfFormat::Bf16 && x86_bf16::native_available();
let expect_gebp = !expect_native_bf16
    && half_prefill_gebp_selected(format, m, k, n)
    && half_prefill_gebp_enabled();
assert_eq!(
    (half_prefill_gebp_calls(), half_native_bf16_calls()),
    (u64::from(expect_gebp), u64::from(expect_native_bf16)), ...);

• A test-only HALF_NATIVE_BF16_CALLS counter on the native bf16 arm distinguishes "took the other fast route" from "silently fell through to the portable blocked half GEMM" — which is what the guardrail is for. Without it, the only way to tolerate the bf16 case is to stop asserting anything.
• (0, 0) on a no-SIMD host is now an asserted-correct outcome instead of a skip.
• The numeric comparison against naive_matmul now runs unconditionally on every host.
• Because the expectation reuses the real predicates, it cannot drift from the dispatch order the way a transcribed condition would.

How I verified it

Transcribed half_gemm_tile's dispatch order and the new expectation into a standalone program and checked them against each other across all 16 combinations of native_available × has_simd_x86 × half_prefill_gebp_enabled × dtype. They agree on all 16.

What I could not verify

I have not reproduced the original failure, and I have not run this test. Stating that plainly rather than implying otherwise.

This host is aarch64 macOS; the test is #[cfg(target_arch = "x86_64")] and x86_bf16::native_available() does not exist here. Cross-compiling is blocked in both directions: x86_64-apple-darwin because upstream publishes no onnxruntime-osx-x86_64-1.28.0.tgz (HTTP 404), and x86_64-unknown-linux-gnu because ort-sys bindgen fails on 'stdlib.h' file not found. onnx-genai-ort-sys is a normal dependency via onnx-runtime-ep-api, so --lib does not avoid it. No Docker on this machine.

So the 16-configuration check verifies the logic is consistent with the dispatch order. It does not verify that the code compiles under target_arch = "x86_64", nor that the counter increments where I placed it. CI is the oracle for both.

A green run on this PR will not prove the fix. It only exercises the (1, 0) branch unless the runner happens to have avx512bf16. The (0, 1) branch — the one that was actually failing — is reachable only on Cooper Lake or newer, and a runner cannot be requested. Corroborating evidence for the mechanism, though: #1609's run went green on Rust coverage (Linux x86_64) and Rust coverage (Windows x86_64) with the old assertion still in place, which is exactly what the CPU-dependence diagnosis predicts and is not evidence that the old test was fine.

Notes

• Touches only crates/onnx-runtime-ep-cpu/src/kernels/matmul.rs. No overlap with Merge the #1186 memory stack (phases 1-7) onto main #1579's file set; nothing in crates/onnx-genai-engine/src/{decode,native_decode}/.
• Based on a429538f, which predates fix(ci): clear the remaining Rust 1.98.0 clippy failures (qmoe, ep-cpu) #1609, so this branch inherits main's CUDA compile (Linux x86_64) red at Clippy CUDA execution provider. That failure is not from this change — fix(ci): clear the remaining Rust 1.98.0 clippy failures (qmoe, ep-cpu) #1609 fixes it.

Refs #1600.

[codecov]

Codecov Report

❌ Patch coverage is 70.00000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.93%. Comparing base (78058a4) to head (e867f8f).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/onnx-runtime-ep-cpu/src/kernels/matmul.rs	70.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1610      +/-   ##
==========================================
- Coverage   80.94%   80.93%   -0.01%     
==========================================
  Files         382      382              
  Lines      178395   178668     +273     
  Branches   178395   178668     +273     
==========================================
+ Hits       144401   144607     +206     
- Misses      29061    29117      +56     
- Partials     4933     4944      +11     

Flag	Coverage Δ
cli-ort-linux	?
cli-ort-windows	82.10% <ø> (ø)
mlas	85.05% <ø> (-0.14%)	⬇️
offline	80.82% <70.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
crates/onnx-runtime-ep-cpu/src/kernels/matmul.rs	82.02% <70.00%> (-0.07%)	⬇️

... and 13 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.