[mono][amd64] Pass and return SIMD values in SIMD registers. by vargaz · Pull Request #93182 · dotnet/runtime

vargaz · 2023-10-07T23:33:28Z

No description provided.

vargaz · 2023-10-11T02:11:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2023-10-11T02:11:52Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-11T03:14:02Z

Can't reproduce the x64 failures.

vargaz · 2023-10-12T05:03:19Z

/azp run runtime

azure-pipelines · 2023-10-12T05:03:52Z

Azure Pipelines successfully started running 1 pipeline(s).

tannergooding · 2023-10-12T16:14:01Z

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).

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

vargaz · 2023-10-18T02:49:43Z

/azp run runtime

azure-pipelines · 2023-10-18T02:50:17Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-18T23:05:06Z

Remaining issues:

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

lateralusX · 2023-10-19T07:37:43Z

@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 · 2023-10-19T07:39:04Z

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 · 2023-10-30T03:36:17Z

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 · 2023-10-30T10:22:27Z

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

XMOVE can be optimized away which creates problems if the argument is on the stack, since mono_spill_global_vars () doesn't process call arguments, it only processes the move instructions before it. If a normal argument is on the stack, it means its volatile/indirect, so its move is not optimized away, but for simd args, they can become indirect when the xcall opcode is decomposed which can happen after the xmove was optimized away, so we end up with code like: ``` ldaddr R19 <- R20 vcall2 voidcall [..] [s:xmm0 <- R20] ```

vargaz · 2023-11-06T06:43:40Z

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 · 2023-12-03T14:52:24Z

Closing for now.

vargaz · 2023-10-07T23:33:28Z

No description provided.

vargaz · 2023-10-11T02:11:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2023-10-11T02:11:52Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-11T03:14:02Z

Can't reproduce the x64 failures.

vargaz · 2023-10-12T05:03:19Z

/azp run runtime

azure-pipelines · 2023-10-12T05:03:52Z

Azure Pipelines successfully started running 1 pipeline(s).

tannergooding · 2023-10-12T16:14:01Z

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).

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

vargaz · 2023-10-18T02:49:43Z

/azp run runtime

azure-pipelines · 2023-10-18T02:50:17Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-18T23:05:06Z

Remaining issues:

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

lateralusX · 2023-10-19T07:37:43Z

@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 · 2023-10-19T07:39:04Z

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 · 2023-10-30T03:36:17Z

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 · 2023-10-30T10:22:27Z

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

XMOVE can be optimized away which creates problems if the argument is on the stack, since mono_spill_global_vars () doesn't process call arguments, it only processes the move instructions before it. If a normal argument is on the stack, it means its volatile/indirect, so its move is not optimized away, but for simd args, they can become indirect when the xcall opcode is decomposed which can happen after the xmove was optimized away, so we end up with code like: ``` ldaddr R19 <- R20 vcall2 voidcall [..] [s:xmm0 <- R20] ```

vargaz · 2023-11-06T06:43:40Z

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 · 2023-12-03T14:52:24Z

Closing for now.

vargaz · 2023-10-07T23:33:28Z

No description provided.

vargaz · 2023-10-11T02:11:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2023-10-11T02:11:52Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-11T03:14:02Z

Can't reproduce the x64 failures.

vargaz · 2023-10-12T05:03:19Z

/azp run runtime

azure-pipelines · 2023-10-12T05:03:52Z

Azure Pipelines successfully started running 1 pipeline(s).

tannergooding · 2023-10-12T16:14:01Z

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).

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

vargaz · 2023-10-18T02:49:43Z

/azp run runtime

azure-pipelines · 2023-10-18T02:50:17Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-18T23:05:06Z

Remaining issues:

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

lateralusX · 2023-10-19T07:37:43Z

@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 · 2023-10-19T07:39:04Z

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 · 2023-10-30T03:36:17Z

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 · 2023-10-30T10:22:27Z

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

XMOVE can be optimized away which creates problems if the argument is on the stack, since mono_spill_global_vars () doesn't process call arguments, it only processes the move instructions before it. If a normal argument is on the stack, it means its volatile/indirect, so its move is not optimized away, but for simd args, they can become indirect when the xcall opcode is decomposed which can happen after the xmove was optimized away, so we end up with code like: ``` ldaddr R19 <- R20 vcall2 voidcall [..] [s:xmm0 <- R20] ```

vargaz · 2023-11-06T06:43:40Z

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 · 2023-12-03T14:52:24Z

Closing for now.

vargaz · 2023-10-07T23:33:28Z

No description provided.

vargaz · 2023-10-11T02:11:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2023-10-11T02:11:52Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-11T03:14:02Z

Can't reproduce the x64 failures.

vargaz · 2023-10-12T05:03:19Z

/azp run runtime

azure-pipelines · 2023-10-12T05:03:52Z

Azure Pipelines successfully started running 1 pipeline(s).

tannergooding · 2023-10-12T16:14:01Z

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).

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

vargaz · 2023-10-18T02:49:43Z

/azp run runtime

azure-pipelines · 2023-10-18T02:50:17Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-18T23:05:06Z

Remaining issues:

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

lateralusX · 2023-10-19T07:37:43Z

@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 · 2023-10-19T07:39:04Z

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 · 2023-10-30T03:36:17Z

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 · 2023-10-30T10:22:27Z

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

XMOVE can be optimized away which creates problems if the argument is on the stack, since mono_spill_global_vars () doesn't process call arguments, it only processes the move instructions before it. If a normal argument is on the stack, it means its volatile/indirect, so its move is not optimized away, but for simd args, they can become indirect when the xcall opcode is decomposed which can happen after the xmove was optimized away, so we end up with code like: ``` ldaddr R19 <- R20 vcall2 voidcall [..] [s:xmm0 <- R20] ```

vargaz · 2023-11-06T06:43:40Z

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 · 2023-12-03T14:52:24Z

Closing for now.

vargaz · 2023-10-07T23:33:28Z

No description provided.

vargaz · 2023-10-11T02:11:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2023-10-11T02:11:52Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-11T03:14:02Z

Can't reproduce the x64 failures.

vargaz · 2023-10-12T05:03:19Z

/azp run runtime

azure-pipelines · 2023-10-12T05:03:52Z

Azure Pipelines successfully started running 1 pipeline(s).

tannergooding · 2023-10-12T16:14:01Z

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).

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

vargaz · 2023-10-18T02:49:43Z

/azp run runtime

azure-pipelines · 2023-10-18T02:50:17Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-18T23:05:06Z

Remaining issues:

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

lateralusX · 2023-10-19T07:37:43Z

@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 · 2023-10-19T07:39:04Z

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 · 2023-10-30T03:36:17Z

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 · 2023-10-30T10:22:27Z

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

XMOVE can be optimized away which creates problems if the argument is on the stack, since mono_spill_global_vars () doesn't process call arguments, it only processes the move instructions before it. If a normal argument is on the stack, it means its volatile/indirect, so its move is not optimized away, but for simd args, they can become indirect when the xcall opcode is decomposed which can happen after the xmove was optimized away, so we end up with code like: ``` ldaddr R19 <- R20 vcall2 voidcall [..] [s:xmm0 <- R20] ```

vargaz · 2023-11-06T06:43:40Z

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 · 2023-12-03T14:52:24Z

Closing for now.

vargaz · 2023-10-07T23:33:28Z

No description provided.

vargaz · 2023-10-11T02:11:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2023-10-11T02:11:52Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-11T03:14:02Z

Can't reproduce the x64 failures.

vargaz · 2023-10-12T05:03:19Z

/azp run runtime

azure-pipelines · 2023-10-12T05:03:52Z

Azure Pipelines successfully started running 1 pipeline(s).

tannergooding · 2023-10-12T16:14:01Z

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).

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

vargaz · 2023-10-18T02:49:43Z

/azp run runtime

azure-pipelines · 2023-10-18T02:50:17Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-18T23:05:06Z

Remaining issues:

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

lateralusX · 2023-10-19T07:37:43Z

@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 · 2023-10-19T07:39:04Z

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 · 2023-10-30T03:36:17Z

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 · 2023-10-30T10:22:27Z

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

XMOVE can be optimized away which creates problems if the argument is on the stack, since mono_spill_global_vars () doesn't process call arguments, it only processes the move instructions before it. If a normal argument is on the stack, it means its volatile/indirect, so its move is not optimized away, but for simd args, they can become indirect when the xcall opcode is decomposed which can happen after the xmove was optimized away, so we end up with code like: ``` ldaddr R19 <- R20 vcall2 voidcall [..] [s:xmm0 <- R20] ```

vargaz · 2023-11-06T06:43:40Z

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 · 2023-12-03T14:52:24Z

Closing for now.

vargaz · 2023-10-07T23:33:28Z

No description provided.

vargaz · 2023-10-11T02:11:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2023-10-11T02:11:52Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-11T03:14:02Z

Can't reproduce the x64 failures.

vargaz · 2023-10-12T05:03:19Z

/azp run runtime

azure-pipelines · 2023-10-12T05:03:52Z

Azure Pipelines successfully started running 1 pipeline(s).

tannergooding · 2023-10-12T16:14:01Z

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).

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

vargaz · 2023-10-18T02:49:43Z

/azp run runtime

azure-pipelines · 2023-10-18T02:50:17Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-18T23:05:06Z

Remaining issues:

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

lateralusX · 2023-10-19T07:37:43Z

@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 · 2023-10-19T07:39:04Z

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 · 2023-10-30T03:36:17Z

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 · 2023-10-30T10:22:27Z

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

XMOVE can be optimized away which creates problems if the argument is on the stack, since mono_spill_global_vars () doesn't process call arguments, it only processes the move instructions before it. If a normal argument is on the stack, it means its volatile/indirect, so its move is not optimized away, but for simd args, they can become indirect when the xcall opcode is decomposed which can happen after the xmove was optimized away, so we end up with code like: ``` ldaddr R19 <- R20 vcall2 voidcall [..] [s:xmm0 <- R20] ```

vargaz · 2023-11-06T06:43:40Z

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 · 2023-12-03T14:52:24Z

Closing for now.

vargaz · 2023-10-07T23:33:28Z

No description provided.

vargaz · 2023-10-11T02:11:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2023-10-11T02:11:52Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-11T03:14:02Z

Can't reproduce the x64 failures.

vargaz · 2023-10-12T05:03:19Z

/azp run runtime

azure-pipelines · 2023-10-12T05:03:52Z

Azure Pipelines successfully started running 1 pipeline(s).

tannergooding · 2023-10-12T16:14:01Z

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).

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

vargaz · 2023-10-18T02:49:43Z

/azp run runtime

azure-pipelines · 2023-10-18T02:50:17Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2023-10-18T23:05:06Z

Remaining issues:

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

lateralusX · 2023-10-19T07:37:43Z

@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 · 2023-10-19T07:39:04Z

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 · 2023-10-30T03:36:17Z

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 · 2023-10-30T10:22:27Z

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

XMOVE can be optimized away which creates problems if the argument is on the stack, since mono_spill_global_vars () doesn't process call arguments, it only processes the move instructions before it. If a normal argument is on the stack, it means its volatile/indirect, so its move is not optimized away, but for simd args, they can become indirect when the xcall opcode is decomposed which can happen after the xmove was optimized away, so we end up with code like: ``` ldaddr R19 <- R20 vcall2 voidcall [..] [s:xmm0 <- R20] ```

vargaz · 2023-11-06T06:43:40Z

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 · 2023-12-03T14:52:24Z

Closing for now.

ghost added the area-Codegen-JIT-mono label Oct 7, 2023

ghost assigned vargaz Oct 7, 2023

vargaz requested a review from lateralusX October 7, 2023 23:33

vargaz force-pushed the amd64-simd-arg branch from 2dd4290 to 932b3c8Compare October 8, 2023 00:01

This was referenced Oct 8, 2023
[7.0][mono][arm64] futex-internal.h: No such file or directory - futex_wait_cancelable native crash in Microsoft.Extensions.Logging.Generators.Roslyn3.11.Tests #87444
Closed
Build crashes in System.Runtime.Serialization.SerializationGuard #92007
Closed

vargaz force-pushed the amd64-simd-arg branch from 932b3c8 to 60118ceCompare October 9, 2023 14:59

build-analysisBot mentioned this pull request Oct 9, 2023
Microsoft.Gen.OptionsValidation.Test.EmitterTests.TestEmitter fails occasionally #93229
Closed

vargaz force-pushed the amd64-simd-arg branch 2 times, most recently from ee2220b to 7098675Compare October 11, 2023 01:36

runfoappBot mentioned this pull request Oct 11, 2023
system.text.regularexpressions.tests work item #72834
Open

vargaz force-pushed the amd64-simd-arg branch 2 times, most recently from 05d0b47 to 0672fb3Compare October 11, 2023 18:47

This was referenced Oct 12, 2023
[wasm][debugger] Debugger tests disabled #89409
Open
The active test run was aborted. Reason: Test host process crashed dotnet/dnceng#451
Closed
Incorrect value in FirstDayOfWeek test #93354
Closed

tannergooding reviewed Oct 12, 2023
View reviewed changes

This was referenced Oct 13, 2023
Test failure: JIT/IL_Conformance/Old/Conformance_Base/ldc_mul_ovf_i4/ldc_mul_ovf_i4.dll #93441
Closed
Test failure: JIT/jit64/rtchecks/overflow/overflow02_mul/overflow02_mul.dll #93442
Closed

vargaz force-pushed the amd64-simd-arg branch from b25cc4b to 53abde4Compare October 17, 2023 23:56

vargaz force-pushed the amd64-simd-arg branch from 53abde4 to 327537bCompare October 18, 2023 02:50

build-analysisBot mentioned this pull request Oct 18, 2023
[wasm] Runtime tests failing - _Vector2_3_4::Vector2_3_4Test.RunVector*Tests because of missing support for native libraries #93669
Closed

vargaz force-pushed the amd64-simd-arg branch from 327537b to 913be6dCompare October 18, 2023 23:03

vargaz marked this pull request as ready for review October 18, 2023 23:04

vargaz requested review from SamMonoRT, fanyang-mono and lambdageek as code owners October 18, 2023 23:04

vargaz changed the title ~~[mono][amd64] Pass SIMD arguments in SIMD registers.~~[mono][amd64] Pass and return SIMD values in SIMD registers.Oct 18, 2023

vargaz mentioned this pull request Oct 20, 2023
[mono][wasm] Pass/receive SIMD arguments by value. #93794
Closed

vargaz force-pushed the amd64-simd-arg branch from c871a75 to 61dc12cCompare October 25, 2023 21:12

build-analysisBot mentioned this pull request Oct 26, 2023
Test failure: Wasm.Build.Tests.NativeBuildTests.MonoAOTCross_WorksWithNoTrimming #93522
Closed

vargaz added 6 commits November 6, 2023 00:09

[mono][amd64] Pass SIMD arguments in SIMD registers.
ae616fa

More fixes.
7e0872d

Return SIMD values in registers as well.
7895482

Implement dyncall support.
e81c022

Implement gsharedvt-in support.
d89493a

vargaz force-pushed the amd64-simd-arg branch from 61dc12c to d89493aCompare November 6, 2023 05:09

vargaz closed this Dec 3, 2023

github-actionsBot locked and limited conversation to collaborators Jan 3, 2024