Add the appropriate ABI handling for the SIMD HWIntrinsic types

[tannergooding]

The SIMD HWIntrinsic types (Vector64<T>. Vector128<T>, and Vector256<T>) are special and represent the __m64, __m128, and __m256 ABI types.

These types have special handling in both the System V and Windows ABI and are treated as "scalar" (e.g. non aggregate and non union) types for the purpose of parameter passing or value returns. They additionally play some role in the selection of MultiReg or HVA (also known as HFA) structs.

We should add the appropriate support for these types to ensure we are meeting the requirement of the underlying ABI for a given platform/system.

category:correctness
theme:runtime
skill-level:expert
cost:large
impact:medium

[jkotas]

This would change calling convention for these types. In general, calling convention changes invalidate pre-compile code out there. I think it would be a good idea to disable loading of these types during crossgen so that they are not baked into any precompiled code and we do not have our hands tied with changing the calling convention.

[tannergooding]

@jkotas, Is there a good example of existing types disabled during crossgen?

I would like to include that change in dotnet/coreclr#15942, if possible.

[jkotas]

Take a look how Vector<T> is handled in vm\methodtablebuilder.cpp. Look for IDS_EE_SIMD_NGEN_DISALLOWED.

[tannergooding]

@jkotas, @CarolEidt. Part of the ABI work for these types is respecting their larger packing sizes (8 for __m64, 16 for __m128, 32 for __m256).

Do you think it is reasonable to have the packing sizes respected for v1 (it looks like it only needs a relatively small update in the VM layer)?

[jkotas]

Do you think it is reasonable to have the packing sizes respected for v1

I think it is reasonable.

[AndyAyersMS]

Should this be in 2.1 (not 2.0.x) ?

[CarolEidt]

Should this be in 2.1 (not 2.0.x) ?

Yes, I believe so.

[tannergooding]

An explicit example of where the current ABI is wrong is for x64 Windows with SIMD returns.

The default calling convention for x64 Windows specifies that __m128, __m128i, and __m128d are returned in XMM0: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019#return-values

These types correspond to the System.Runtime.Intrinsics.Vector128 type on the managed side and it is not currently being returned in XMM0.

dotnet/coreclr#23899 adds support for passing Vector128 across interop boundaries and so this will need to be correctly handled.