Test failure for TensorPrimitives MinNumber and MaxNumber on Arm64

[tannergooding]

Build Information

Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=673236
Build error leg or test failing: System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanSpanDestination_SpecialValues
Pull request: #102098

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "",
  "ErrorPattern": "Single (MaxNumber|MinNumber)\\(Single, Single\\).*\\[FAIL\\]",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=673236
Error message validated: [Single (MaxNumber|MinNumber)\(Single, Single\).*\[FAIL\]]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 5/13/2024 1:17:52 PM UTC

Report

Build	Definition	Test	Pull Request
673236	dotnet/runtime	System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanSpanDestination_SpecialValues	#102098
2449946	dotnet-runtime	System.Numerics.Tensors.Tests.SingleGenericTensorPrimitives.SpanSpanDestination_SpecialValues

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
2	2	2

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics-tensors
See info in area-owners.md if you want to be subscribed.

[tannergooding]

This is failing for -sNaN as the Arm64 FMINNM and FMAXNM instructions behave as per the IEEE 754:2008 rules where the handling of min/max was first attempted to be normalized.

The IEEE 754:2008 rules are:

minNum(x, y) is the canonicalized number x if x < y, y if y < x, the canonicalized number if one
operand is a number and the other a quiet NaN. Otherwise it is either x or y, canonicalized (this
means results might differ among implementations). When either x or y is a signalingNaN, then the
result is according to 6.2.

Where 6.2 details:

Under default exception handling, any operation signaling an invalid operation exception and for which a
floating-point result is to be delivered shall deliver a quiet NaN.

However, this was further rectified in the IEEE 754:2019 standard to remove the remaining ambiguities that existed:

minimumNumber(x, y) is x if x < y, y if y < x, and the number if one operand is a number and the
other is a NaN. For this operation, −0 compares less than +0. If x = y and signs are the same it is
either x or y. If both operands are NaNs, a quiet NaN is returned, according to 6.2. If either
operand is a signaling NaN, an invalid operation exception is signaled, but unless both operands
are NaNs, the signaling NaN is otherwise ignored and not converted to a quiet NaN as stated in
6.2 for other operations.

Noting the important changes being that -0 < +0 and that sNaN is not converted to qNaN when only one of the inputs is NaN.

As such, the Arm64 handling needs to be adjusted to handle sNaN as per the IEEE 754 requirements. This isn't currently an issue for float.MinNumber because its not generating FMINNM, it's using the software fallback. It's likewise not showing up as an issue for various cases involving a constant because the GenTreeDblCon node type only stores a double and the upcast from float to double is enough to normalize the value in many cases.