What is the rationale for Vector128.ConvertToDouble having a codepath for SSE2 in C#?

[tgjones]

I notice that the implementation of Vector128.ConvertToDouble contains C# with a codepath specifically for SSE2, with a fallback to calling Vector64.ConvertToDouble for the lower and upper parts of the vector.

But (as far as I can tell) this method also has JIT support:

• ARM64
• X64

My question is: why does the if (Sse2.IsSupported) branch exist in C#?

• why not implement that optimization entirely in the JIT?
• or why not implement it all in C# instead of the JIT?

I'm really interested in the rationale behind this.

(I'm interested in the general pattern for all cross-platform SIMD intrinsic APIs, but it seemed better to frame this as a question about this specific API. I'd guess that the answer may be similar for the general case.)

cc @tannergooding

[tannergooding]

But (as far as I can tell) this method also has JIT support:

For x64, this is notably only done when Avx512F or Avx10v1 is available. This fallsback to the managed implementation for hardware with only [SSE2, AVX2] support

why not implement that optimization entirely in the JIT?

Not all code is trivial to implement in the JIT, due to the size of the IR required to be inserted. In the case of ConvertToDouble, there are 7-9 IR nodes that need to be inserted for this operation.

Sometimes, particularly for methods where it isn't critical to have it done in the JIT we instead do it in managed for simplicity. In many cases its just point in time and it would be possible to add a path to the JIT instead, it just hasn't been a high enough priority.

or why not implement it all in C# instead of the JIT?

Some APIs are simply not possible to implement in C#. Which is to say, the various Vector###<T> types are what are known as "ABI primitives" and have special requirements that only the underlying compiler that emits machine code can fulfill; the same is true of types like float, double, int32, int64, etc. This is distinct from "user-defined structs" which are things that a user can define and which are built up using such primitives. -- Such types exist in all languages and are defined by the ABI (Application Binary Interface) specification for a given OS + Architecture combination.

Additionally, the foundational APIs are generally considered "perf critical" and are often used very densely together. Because of this, we'd end up seeing non-trivial impact to JIT compilation throughput and likely some minor code artifacts if every single one of these APIs, which often compile down to 1 single instruction, had to instead first have the IL for 3-4 architectures each with 1-5 ISAs inlined, had to then have the dead code paths eliminated (which is the majority of them), had to have the branches removed and rationalized to be the single IR node, and then finish the compilation. So these foundational APIs are instead marked [Intrinsic] and the JIT special cases them to skip the vast majority of this work and just produce the relevant IR nodes directly (improving JIT compilation throughput and having a minor benefit to code quality at the extreme scale).

[tgjones]

Thank you, that's very helpful.