onnxruntime_mlas_test is built in CI but never executed #33052

Summary

onnxruntime_mlas_test is compiled by CI and then never executed. The MLAS unit tests —
32447 registered cases — are built on every platform and discarded.

I ran into this after #33040: the test I added there, the extreme-value coverage merged in
#32631, and the additions in #33050 do not run in CI, so none of them protect anything
today.

Evidence

No ctest registration anywhere. cmake/onnxruntime_unittests.cmake:2333 creates the
target with onnxruntime_add_executable(onnxruntime_mlas_test ...) and there is no
add_test() for it in any cmake file. ctest therefore cannot run it on any platform. This
is the conclusive part; the rest is confirmation.

Not run by any pipeline. No file under tools/ci_build/github/ references
onnxruntime_mlas_test.

Observed in a real run. In Build Linux arm64 Debug for #33040
(job)
the binary is built at step 1500/1609 and appears in 58 log lines, all of them
Building CXX object or Linking. It is never invoked. The ctest roster for that job is:

Test  #1: onnxruntime_test_all          Test  #7: onnxruntime_global_thread_pools_test
Test  #2: onnxruntime_provider_test     Test  #8: onnxruntime_customopregistration_test
Test  #3: onnx_test_pytorch_converted   Test  #9: onnxruntime_autoep_test
Test  #4: onnx_test_pytorch_operator    Test #10: onnxruntime_logging_apis_test
Test  #5: onnxruntime_cpuinfo_refcount_test   Test #11: onnxruntime_ep_graph_test
Test  #6: onnxruntime_shared_lib_test

100% tests passed, 0 tests failed out of 11. MLAS is not among them.

Why this probably is not an oversight, and what I would ask instead

I measured the suite before assuming anything. On 4 cores in a Linux arm64 VM
(onnxruntime_USE_SVE=ON, Release):

850 s per PR is a real cost, and I assume that is why this is not wired up. A dedicated CI
machine may be faster than my numbers, but the ratio is the interesting part: the second row
covers the ARM fp16 kernel surface — including both places where #32631 and #33040 found
real bugs — for 23 seconds.

So rather than propose a config change to everyone's pipeline, the question for you:

1. A targeted filter in PR CI (seconds), with the full suite nightly or scheduled?
2. The full suite in a single existing arm64 job only?
3. Deliberately left out, in which case it would help to say so near the target in
   onnxruntime_unittests.cmake, since the natural assumption on adding an MLAS test is
   that CI will run it.

One caveat worth knowing before choosing

In the 23 s filtered run, 8 tests skip: the SVE suites, because the runner has no SVE
(HasArmSve() is false). So wiring the test in would catch NEON fp16 regressions but still
not the SVE bugs fixed in #33040 — those paths are compiled (build.py enables
onnxruntime_USE_SVE unless --no_sve) and never executed anywhere.

Covering them needs either an SVE-capable runner or emulation. qemu-aarch64 -cpu max
provides SVE under TCG, and because the vector length is selectable at runtime via
prctl(PR_SVE_SET_VL) a single binary can sweep all 16 lengths from 128 to 2048 bits. That
is how #33040 was validated, and both bugs there were lane-position dependent, so the sweep
mattered. I am happy to put that up as a separate job if there is appetite for it.

Offer

I will send a PR for whichever of the three you prefer. I would rather ask first than change
CI runtime for every contributor on an assumption.

If I have missed a pipeline that does run this, please say and I will close this.