[mono][amd64] Pass and return SIMD values in SIMD registers.

[vargaz]

No description provided.

[vargaz]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[vargaz]

Can't reproduce the x64 failures.

[vargaz]

/azp run runtime

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tannergooding]

Is it intentional this doesn't match the native ABI for the platform?

There are particular rules for when and how certain SIMD types are passed depending on the ABI of the underlying platform (Windows x64, Unix SysV, etc).

[vargaz]

This is just an experiment right now, it has many problems, including this one.

[vargaz]

/azp run runtime

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[vargaz]

Remaining issues:

• windows support
• dyncalls (method invokes)
• gsharedvt (not really used on amd64 in production)
• non 16 byte types

[lateralusX]

Remaining issues:

• windows support
• dyncalls (method invokes)
• gsharedvt (not really used on amd64 in production)
• non 16 byte types

@vargaz What happens if gsharedvt is used, will we fallback and use none SIMD regs as we did before this PR or will just not when having SIMD types in parameters or return type?

[lateralusX]

Remaining issues:

• windows support
• dyncalls (method invokes)
• gsharedvt (not really used on amd64 in production)
• non 16 byte types

I will look into windows support for this, working on it in a downstream repro to see how it behaves and will then upstream. Don't think that should block us from progressing on this PR.

[vargaz]

Another significant problem is that the generic instances used by generic sharing like Vector<T_INT> are not marked as simd types, so for T return_t<T> (T t), the return_t<Vector<int>> instance has a different calling convention than the shared return_t<Vector<T_INT>>) instance, which is not going to work.

[lateralusX]

Another significant problem is that the generic instances used by generic sharing like Vector<T_INT> are not marked as simd types, so for T return_t<T> (T t), the return_t<Vector<int>> instance has a different calling convention than the shared return_t<Vector<T_INT>>) instance, which is not going to work.

I guess it will be possible for caller to detect this scenario and choose calling convention accordingly?

[vargaz]

So it looks like gshared support for the simd types cannot really be enabled right now, because gsharing for primitive types works by erasing the difference between primitive types and enums, so a Vector128<T_INT> can be instantiated by both an int an enums whose base type is int, but the simd types don't allow enum element types.
So if gsharing is enabled for vectors, then this code:

public static void foo<T> (Vector128<T> v1, Vector128<T> v2) {
        for (int i = 0; i < 10000000; ++i)
            v1 = v1 + v2;
}

foo<AnEnum> (default(Vector128<AnEnum>), default(Vector128<AnEnum>));

will no longer throw an exception.

[vargaz]

Closing for now.