[MLAS] test: accept canonical NaN in activation NaN round-trip check#28538
Merged
hariharans29 merged 1 commit intoMay 19, 2026
Merged
Conversation
MlasActivationTest feeds NaN inputs and asserts the output matches the expected value bit-for-bit. For activation kinds that go through floating -point arithmetic (e.g. LeakyRelu, HardSigmoid) this assumes the input NaN payload is preserved. IEEE-754 does not require NaN payload propagation and some ISAs canonicalize it -- RISC-V, for instance, produces the canonical quiet NaN (0x7fc00000) for any arithmetic NaN result -- so the bit-exact check fails there even though a NaN input correctly produced a NaN output. Accept any NaN output when the expected value is a NaN. Non-NaN comparisons are unchanged. Signed-off-by: qiurui144 <happyqiurui@163.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates an MLAS activation unit test to accept architecture-valid NaN canonicalization behavior during scalar activation checks.
Changes:
- Allows any NaN output to pass when the expected activation result is also NaN.
- Keeps existing exact and tolerance-based comparisons unchanged for non-NaN outputs.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
hariharans29
approved these changes
May 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
MlasActivationTest.ExecuteShort(test_activation.cpp) feeds NaN inputsthrough
MlasActivationand asserts the output matches the expected valuebit-for-bit. This change adds one accepted case: when the expected value is a
NaN, any NaN output passes.
Non-NaN comparisons are unchanged — a finite output where a NaN is expected
(or the reverse) still fails. Test-only change, no library behavior impact.
Verified:
onnxruntime_mlas_test --gtest_filter=Activation.ShortExecuteonSpacemiT K3 (riscv64, RVV VLEN=256), rv-gcc 15.2 — FAILED before, PASSED
after (re-run x3). x86/x64 behavior unaffected.
Motivation and Context
The bit-exact assertion (
Buffer[i].u == TestData[i][kind].u) implicitlyassumes the input NaN payload survives the activation. For kinds evaluated by
floating-point arithmetic — LeakyRelu (
alpha * x), HardSigmoid(
alpha * x + beta) — that only holds on ISAs that propagate NaN payloads(x86, ARM).
IEEE-754 does not require NaN payload propagation. RISC-V's
Fextensionmandates that any FP operation producing a NaN yields the canonical quiet NaN
(
0x7fc00000for f32), discarding the payload. So on riscv64 these kinds emit0x7fc00000for a NaN input — a correct "NaN in → NaN out" result whose bitpattern simply differs from the input — and the bit-exact check fails.
Accepting any NaN where a NaN is expected restores the test to the portable
IEEE-754 contract.