Use AVX512 intrinsics for numeric conversion in JIT

[martinothamar]

Jit version of #89330

For Vector128.ConvertToDouble

Before

G_M000_IG02:                ;; offset=0x0007
       call     [OthmarTesting.Testing:Src():long]
       vpbroadcastq  xmm0, rax
       vpblendd xmm1, xmm0, xmmword ptr [reloc @RWD00], 10
       vpsrlq   xmm0, xmm0, 32
       vpxorq   xmm0, xmm0, qword ptr [reloc @RWD16] {1to2}
       vsubpd   xmm0, xmm0, qword ptr [reloc @RWD24] {1to2}
       vaddpd   xmm0, xmm0, xmm1
       vmovups  xmmword ptr [rbx], xmm0
       mov      rax, rbx

After

G_M000_IG02:                ;; offset=0x0007
       call     [OthmarTesting.Testing:Src():long]
       vpbroadcastq  xmm0, rax
       vcvtqq2pd xmm0, xmm0
       vmovups  xmmword ptr [rbx], xmm0
       mov      rax, rbx

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Jit version of #89330

For Vector128.ConvertToDouble

Before

G_M000_IG02:                ;; offset=0x0007
       call     [OthmarTesting.Testing:Src():long]
       vpbroadcastq  xmm0, rax
       vpblendd xmm1, xmm0, xmmword ptr [reloc @RWD00], 10
       vpsrlq   xmm0, xmm0, 32
       vpxorq   xmm0, xmm0, qword ptr [reloc @RWD16] {1to2}
       vsubpd   xmm0, xmm0, qword ptr [reloc @RWD24] {1to2}
       vaddpd   xmm0, xmm0, xmm1
       vmovups  xmmword ptr [rbx], xmm0
       mov      rax, rbx

After

G_M000_IG02:                ;; offset=0x0007
       call     [OthmarTesting.Testing:Src():long]
       vpbroadcastq  xmm0, rax
       vcvtqq2pd xmm0, xmm0
       vmovups  xmmword ptr [rbx], xmm0
       mov      rax, rbx

Author:	martinothamar
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[martinothamar]

Should I implement these hardware intrinsics for Vector<T> (simdashwintrinsic.cpp) as well? I see that NI_VectorT128_ConvertToDouble for example is only accelerated under ARM64

[adamsitnik]

@dotnet/avx512-contrib the previous PR (#89330) provided by @martinothamar was left with no feedback for over two months, please don't let this PR become stale too.

[tannergooding]

We appreciate the PR, but this is not something we'll be able to take at this time.

There are longer discussions covering the reasons why in #84384 and #61885, but in essence we have a desire to ensure the default behavior is deterministic across platforms.

This entails us not simply executing the direct instruction, but also doing the work to ensure that overflow results in saturation, rather than returning some sentinel value and doing the equivalent work to ensure that scalars, constant folding, and other paths all have the same behavior. This work is significantly more involved and requires additional testing, general integration, etc.

As such, it is work that we will be doing ourselves when the time is appropriate (this will likely be in the next few months).

[martinothamar]

Ahh I see that makes sense, thanks for the quick reply. I'll go ahead and close the other PR as well