[mono] Pass Vector64, Vector128, and Vector256 in SIMD registers whenever possible

[imhameed]

In particular this should work for FFI calls, so we should respect the target platform's common calling convention(s).

An similar example is 128-bit vectors for amd64.

Handles input arguments:

• LLVM
  • Arm64
  • Amd64
• mini
  • Arm64
  • Amd64
• interpreter

Handles return argument:

• LLVM
  • Arm64
  • Amd64
• mini
  • Arm64
  • Amd64
• interpreter

[lambdageek]

Would allow us to run these tests https://github.com/dotnet/runtime/tree/main/src/tests/Interop/PInvoke/Generics and implement mono/mono#17868

A related issue #9578 is tracking the CoreCLR work to unblock passing Vector128/Vector256 by value to P/Invokes. It's currently blocked (with a bad error message about the types not being blittable) due to CoreCLR incorrectly marshalling vector return values on Windows x64.

A related issue is for CoreCLR to implement support for __vectorcall on Windows #8300

[lambdageek]

A specific use-case is to be able to call Apple platform APIs that have some arguments that have types with a __ext_vector_type attribute. (see the Mono issue linked above)

[lambdageek]

We would need this across the board: LLVM, mini and interp should support it.

[fanyang-mono]

When using LLVM as codegen backend, LLVM is able to does the work of sending the data to SIMD register before the operation. Here is an example from x64

c# code

using System;
using System.Runtime.Intrinsics;
using System.Runtime.Intrinsics.Arm;
using System.Runtime.CompilerServices;
using System.Numerics;

namespace HelloWorld
{
    internal class Program
    {
        [MethodImpl(MethodImplOptions.NoInlining)]
        private static Vector128<int> test(Vector128<int> a, Vector128<int> b, Vector128<int> c)
        {
            return Vector128.Min(a,b);
        }

        private static void Main(string[] args)
        {
            Vector128<int> A = Vector128.Create((int)3.1);
            Vector128<int> B = Vector128.Create((int)5.7);
            Vector128<int> C = Vector128.Create((int)50);

            var result = test(A, B, C);
            Console.WriteLine(result);
        }
    }
}

When LLVM is enabled:

*** ASM for HelloWorld.Program:test (System.Runtime.Intrinsics.Vector128`1<int>,System.Runtime.Intrinsics.Vector128`1<int>,System.Runtime.Intrinsics.Vector128`1<int>) ***
/var/folders/9q/30znkg553fb1vt7_qnx2v0040000gn/T/.44S0Ml:
(__TEXT,__text) section
loWorld_Program_test__System_Runtime_Intrinsics_Vector128_1_int__System_Runtime_Intrinsics_Vector128_1_int__System_Runtime_Intrinsics_Vector128_1_int__:
0000000000000000	vmovq	%rdx, %xmm0
0000000000000005	vmovq	%rsi, %xmm1
000000000000000a	vpunpcklqdq	%xmm0, %xmm1, %xmm0
000000000000000e	vmovq	%r8, %xmm1
0000000000000013	vmovq	%rcx, %xmm2
0000000000000018	vpunpcklqdq	%xmm1, %xmm2, %xmm1
000000000000001c	vpminsd	%xmm1, %xmm0, %xmm0
0000000000000021	vmovdqu	%xmm0, (%rdi)
0000000000000025	retq

Thus, this work actually only apply to mini and interp.

[lambdageek]

@fanyang-mono
In your example see how the arguments are actually passed in %rdx and %rsi and then moved into %xmm0 and %xmm1:

0000000000000000	vmovq	%rdx, %xmm0
0000000000000005	vmovq	%rsi, %xmm1

What this issue is about is two things:

1. making managed-to-managed calls utilize a calling convention where those Vector128<int> arguments oculd be passed in SIMD registers directly (so those movs aren't needed - the arguments would already be in %xmm0 and `%xmm1).
2. The same thing but for PInvokes (ie managed calling unmanaged). Which is also what [Xamarin.iOS] Add runtime support for SIMD types mono/mono#17868 is about.

These two problems could be tackled separately: we could just do the managed-to-managed calls first. But we would still need to do something for LLVM (as your example shows)

[fanyang-mono]

Gotcha!

[fanyang-mono]

Nice to have, moving to 8.0.0

[fanyang-mono]

This is a tracking issue. Moving it to .NET9.

[lewing]

cc @steveisok @vargaz