Updating the VM to no longer treat the SIMD HWIntrinsic types as HFA or MultiReg structs

[tannergooding]

Prior to #15897, these (Vector64<T>, Vector128<T>, and Vector256<T>) were explicitly sized types with 0 introduced fields, so they would fall out of these checks and would not be treated as HFA or MultiReg structs.

After the change, these began being treated as 2-field Integer aggregates which caused them to be passed around incorrectly.

After discussion with @CarolEidt, we agreed that disabling the HFA/MultiReg handling for these types was the best/easiest solution for the time being.

At some point in the future, we should add in the proper handling for these types and treat them as the __m64, __m128, and __m256 scalar (e.g. non aggregate and non union) types which are defined in the System V and Windows ABIs.

[tannergooding]

FYI. @CarolEidt, @jkotas, @fiigii, @sdmaclea

[tannergooding]

@CarolEidt, @jkotas.

I initially tried to do this in the JIT, but there are a lot of assumptions for any type which has had the SYSTEMV_AMD64_CORINFO_STRUCT_REG_PASSING_DESCRIPTOR filled out by the VM. So I moved the checks to the VM layer where the descriptor is created.

[tannergooding]

Logged https://github.com/dotnet/coreclr/issues/15943, to track adding the proper ABI support for these types.

[tannergooding]

test Windows_NT x64 Checked jitincompletehwintrinsic
test Windows_NT x64 Checked jitx86hwintrinsicnoavx
test Windows_NT x64 Checked jitx86hwintrinsicnoavx2
test Windows_NT x64 Checked jitx86hwintrinsicnosimd
test Windows_NT x64 Checked jitnox86hwintrinsic

test Windows_NT x86 Checked jitincompletehwintrinsic
test Windows_NT x86 Checked jitx86hwintrinsicnoavx
test Windows_NT x86 Checked jitx86hwintrinsicnoavx2
test Windows_NT x86 Checked jitx86hwintrinsicnosimd
test Windows_NT x86 Checked jitnox86hwintrinsic

test Ubuntu x64 Checked jitincompletehwintrinsic
test Ubuntu x64 Checked jitx86hwintrinsicnoavx
test Ubuntu x64 Checked jitx86hwintrinsicnoavx2
test Ubuntu x64 Checked jitx86hwintrinsicnosimd
test Ubuntu x64 Checked jitnox86hwintrinsic

test OSX10.12 x64 Checked jitincompletehwintrinsic
test OSX10.12 x64 Checked jitx86hwintrinsicnoavx
test OSX10.12 x64 Checked jitx86hwintrinsicnoavx2
test OSX10.12 x64 Checked jitx86hwintrinsicnosimd
test OSX10.12 x64 Checked jitnox86hwintrinsic

[sdmaclea]

At some point in the future, we should add in the proper handling for these types and treat them as the __m64, __m128, and __m256 scalar (e.g. non aggregate and non union) types which are defined in the System V and Windows ABIs.

ARM64 may be different, but it would be nice if it was the same.

Maybe we should have/require a cast operator to ABI compatible type to support interop with C++ ABI.

[tannergooding]

@sdmaclea. The Procedure Call Standard for the
ARM® Architecture (AAPCS) defines these types specially as well and treats them as "fundamental data types" (which is equivalent to the "scalar" data types in the x64 ABI). It also has rules for passing and returning "VFP and Advanced SIMD Register Arguments" which take advantage of the available registers.

[tannergooding]

All failures are known issues unrelated to this change (https://github.com/dotnet/coreclr/issues/15924 and https://github.com/dotnet/coreclr/issues/15848).

[tannergooding]

Updated to prevent the SIMD hardware intrinsic types from being loaded during crossgen, as per https://github.com/dotnet/coreclr/issues/15943#issuecomment-359144600

[fiigii]

@jkotas @CarolEidt If SIMD types are disabled for ABI, how can we enable HW intrinsics for crossgen (or other AOT platforms) in the future?

[jkotas]

One we have the right stable ABI for the Vector64/128/256 types, we can re-enable it for crossgen/AOT.

[jkotas]

@tannergooding Could you please update the comment to capture this?

[tannergooding]

Updated to additionally include the following comment: Once they are properly handled according to the ABI requirements, we can remove this check and allow them to be used in crossgen/AOT scenarios.

[4creators]

test Ubuntu x64 Checked jitincompletehwintrinsic
test Ubuntu x64 Checked jitx86hwintrinsicnoavx
test Ubuntu x64 Checked jitx86hwintrinsicnoavx2
test Ubuntu x64 Checked jitx86hwintrinsicnosimd
test Ubuntu x64 Checked jitnox86hwintrinsic

test OSX10.12 x64 Checked jitincompletehwintrinsic
test OSX10.12 x64 Checked jitx86hwintrinsicnoavx
test OSX10.12 x64 Checked jitx86hwintrinsicnoavx2
test OSX10.12 x64 Checked jitx86hwintrinsicnosimd
test OSX10.12 x64 Checked jitnox86hwintrinsic

[4creators]

test Windows_NT x64 Checked jitincompletehwintrinsic
test Windows_NT x64 Checked jitx86hwintrinsicnoavx
test Windows_NT x64 Checked jitx86hwintrinsicnoavx2
test Windows_NT x64 Checked jitx86hwintrinsicnosimd
test Windows_NT x64 Checked jitnox86hwintrinsic

test Windows_NT x86 Checked jitincompletehwintrinsic
test Windows_NT x86 Checked jitx86hwintrinsicnoavx
test Windows_NT x86 Checked jitx86hwintrinsicnoavx2
test Windows_NT x86 Checked jitx86hwintrinsicnosimd
test Windows_NT x86 Checked jitnox86hwintrinsic

[sdmaclea]

ARM® Architecture (AAPCS) defines these types specially as well and treats them as "fundamental data types"

👍

I see them referred to as Short Vectors in AAPCS. I had ignored them, because @jkotas had indicated they were not supported. Sounds like we need to fully support as part of HW intrinsics.

[CarolEidt]

These changes look reasonable to me but @jkotas should be the one to approve these.

[jkotas]

LGTM