onnxruntime

6f6e8815 - [MLAS] Fix Inf/NaN comparison and add fp16 extreme-value coverage for ARM64 HGEMM NEON (#31761)

[MLAS] Fix Inf/NaN comparison and add fp16 extreme-value coverage for ARM64 HGEMM NEON (#31761) ## Summary `test_hgemm_neon.cpp`'s four arithmetic test classes (`MlasNeonHGemmTransposedBTest`, `MlasNeonHGemmBTest`, `MlasNeonHGemmPackedBTest`, `MlasNeonHGemmTest`) only ever fill operands via a `uniform_real_distribution` restricted to `[-1,1]` or `[-0.25,0.25]`. Even the largest shapes (K up to 513) never come close to fp16 overflow (max ~65504) since the accumulated magnitude stays well under that. `FloatEqual` (duplicated identically across all four classes) also mishandles Inf/NaN: ```cpp return std::abs(f0 - f1) <= std::abs(f1 * rtol) + atol; ``` `Inf == Inf` computes `abs(Inf-Inf) = NaN`, and `NaN <= Inf` is false, so two matching infinities fail the comparison. Conversely, a finite kernel output against an Inf reference computes `abs(finite-Inf) = Inf <= Inf`, which is true -- a dropped overflow passes silently. Extracted the function into a single free function with explicit Inf/NaN handling; the existing finite-value branch is untouched. Added `TestHGemmFixed<>` to each class, filling operands with fixed extreme fp16 values instead of the random distribution: near max magnitude, alpha/beta scaling that pushes into overflow, and subnormal-range products. Values were chosen to land in ranges where the kernel's native fp16 accumulation and the reference's fp32-then-round accumulation agree. Large-magnitude operands combined with large K diverge past the existing `rtol=0.02`/`atol=0.055` tolerance from fp16's accumulation error alone (confirmed by measurement, e.g. `a=10,b=1,K=513` gives 4928 vs a 5128 reference), so those combinations are deliberately avoided rather than loosening the tolerance. `MlasNeonHGemmPackBTest` is left untouched: `HPackB_TransposedB_Kernel`/`HPackB_B_Kernel` only move data, and `Check<N,K>` already compares raw bit patterns (`ASSERT_EQ(packed[...].val, ref[...].val)`), so `FloatEqual`'s defect doesn't apply there. Test-only change; no file under `onnxruntime/core/mlas/lib/` is touched. ## Testing `test_hgemm_neon.cpp` only builds under `MLAS_F16VEC_INTRINSICS_SUPPORTED && MLAS_TARGET_ARM64`; under the default build configuration that excludes Apple targets (`mlas.h` disables fp16 vector intrinsics under `__APPLE__`), so verification was done on a non-Apple ARM64 host. Neoverse-N1 (Oracle Cloud A1, Ubuntu): - `*NeonHGemm*`: 5/5 passed (all five suites, including the new extreme-value cases) - Full `onnxruntime_mlas_test` suite: 36020/36020 passed, no regressions