Ensure that the TensorPrimitives.Min/MaxNumber functions follow the IEEE 754:2019 spec #102162
Conversation
…EEE 754:2019 spec
ghost
added
the
|
Tagging subscribers to this area: @dotnet/area-system-numerics |
...es/System.Numerics.Tensors/src/System/Numerics/Tensors/netcore/TensorPrimitives.MaxNumber.cs
Outdated
Show resolved
Hide resolved
...es/System.Numerics.Tensors/src/System/Numerics/Tensors/netcore/TensorPrimitives.MinNumber.cs
Outdated
Show resolved
Hide resolved
|
|
||
| Vector128<T> max; | ||
|
|
||
| if (Sse.IsSupported && typeof(T) == typeof(float)) |
There was a problem hiding this comment.
Nit: presumably this change is unrelated to the test fix at hand, would it be possible to update the PR title/commit message to include this change?
There was a problem hiding this comment.
It's not a change. It's preserving the behavior and perf for xarch from prior to this PR
There was a problem hiding this comment.
That is, Vector128.Min on xarch currently emits minps/minpd (Sse.Min for float and Sse2.Min for double) while on Arm64 it emits fmin.
We therefore cannot use Vector128.Min on Arm64 since it propagates NaN (and longterm wouldn't work for xarch either, as we're working towards ensuring consistency there). But, it's safe to continue using the underlying intrsinsics for xarch as part of the MinNumber algorithm and thus allows us to preserve codegen as-is there.
(same general commentary applies to MaxNumber)
Co-authored-by: Stephen Toub <stoub@microsoft.com>
…EEE 754:2019 spec (dotnet#102162) * Ensure that the TensorPrimitives.Min/MaxNumber functions follow the IEEE 754:2019 spec * Apply suggestions from code review Co-authored-by: Stephen Toub <stoub@microsoft.com> --------- Co-authored-by: Stephen Toub <stoub@microsoft.com>
This resolves #102156