Update Mono to handle various other vector bitcast APIs by tannergooding · Pull Request #104049 · dotnet/runtime

tannergooding · 2024-06-26T16:27:00Z

This should resolvedotnet/perf-autofiling-issues#36484

dotnet-policy-service · 2024-06-26T16:27:27Z

Tagging subscribers to this area: @steveisok, @lambdageek
See info in area-owners.md if you want to be subscribed.

kg · 2024-06-26T19:53:42Z

At a glance this all looks good. If the regression still isn't gone after this on wasm, I can help implement the new intrinsics in the jiterpreter.

tannergooding · 2024-06-26T19:56:39Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

The mono interp handling for AsVector2Single seems to not be quite right though, so I'll see if I can fix that first. Edit: The interp failure was a simple typo

steveisok · 2024-06-26T20:50:06Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

#104028 should make it better. All ios/tvos device runs were failing before this.

tannergooding · 2024-06-26T20:51:58Z

Glad to know it wasn't something on my end, hopefully this is green and can get merged as it should give us some nice improvements 🎉

tannergooding · 2024-06-27T03:32:57Z


 static gboolean
-get_common_simd_info (MonoClass *vector_klass, MonoMethodSignature *csignature, MonoTypeEnum *atype, int *vector_size, int *arg_size, int *scalar_arg)
+get_common_simd_info (MonoClass *klass, MonoTypeEnum *atype, int *klass_size, int *arg_size)


This file ended up needing a bit of a refactoring as there were some assumptions in place that don't hold when supporting additional intrinsics.
In particular, there are various intrinsics where:
one of the SIMD types may not be generic at all (Vector2, Vector3, Vector4)
multiple generic types exist (As<TFrom, TTo>)
the return type may not be a 128-bit vector (AsVector2, AsVector3)
So, what I did here was I broke this get_common_simd_info method into two:
get_common_simd_info
get_common_simd_scalar_arg
The former now always gets the size of the input klass and secondly determines if it is a SIMD type and what the underlying element type is if so. While the latter identifies the first non-SIMD argument, if one exists.

tannergooding · 2024-06-27T03:33:35Z


 static void
-emit_common_simd_epilogue (TransformData *td, MonoClass *vector_klass, MonoMethodSignature *csignature, int vector_size, gboolean allow_void)
+emit_common_simd_epilogue (TransformData *td, MonoMethodSignature *csignature)


To support methods which return a value type, but where that isn't a 128-bit vector, this explicitly gets the return type from the signature to ensure there can be no accidents

tannergooding · 2024-06-27T03:37:29Z

 	gint16 simd_intrins = -1;

-	vector_klass = mono_class_from_mono_type_internal (csignature->ret);
+	MonoTypeEnum ret_atype;


In here, we consistently query the relevant simd information of the return type and if it exists the simd information of the first parameter (this is enough to correctly handle all the cases that currently exist).
There's actually quite a bit of logic in this function that could be moved down into emit_common_simd_operations, as APIs like AndNot exist for Vector128<T> and Vector<T>, they may also exist for types like Vector4 in the future. I opted to not move that down in this PR, to try and keep the total churn under control.
But, I did add some basic validation that the encountered signatures are roughly as expected to help ensure we don't hit issues in the future as new overloads are introduced or the general SIMD support in Mono is expanded.

tannergooding · 2024-06-28T21:34:30Z

Similarly to #103915, I don't have the time to continue to try and debug why these changes aren't working for Mono.

Anyone should feel free to pick this up if they have more context or time.

-- As it stands, there appears to be some quirk where Mono is either incorrectly doing comparisons or other handling around Vector3 and it's causing most of the downstream failures.

tannergooding · 2024-06-26T16:27:00Z

This should resolvedotnet/perf-autofiling-issues#36484

dotnet-policy-service · 2024-06-26T16:27:27Z

Tagging subscribers to this area: @steveisok, @lambdageek
See info in area-owners.md if you want to be subscribed.

kg · 2024-06-26T19:53:42Z

At a glance this all looks good. If the regression still isn't gone after this on wasm, I can help implement the new intrinsics in the jiterpreter.

tannergooding · 2024-06-26T19:56:39Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

The mono interp handling for AsVector2Single seems to not be quite right though, so I'll see if I can fix that first. Edit: The interp failure was a simple typo

steveisok · 2024-06-26T20:50:06Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

#104028 should make it better. All ios/tvos device runs were failing before this.

tannergooding · 2024-06-26T20:51:58Z

Glad to know it wasn't something on my end, hopefully this is green and can get merged as it should give us some nice improvements 🎉

tannergooding · 2024-06-27T03:32:57Z


 static gboolean
-get_common_simd_info (MonoClass *vector_klass, MonoMethodSignature *csignature, MonoTypeEnum *atype, int *vector_size, int *arg_size, int *scalar_arg)
+get_common_simd_info (MonoClass *klass, MonoTypeEnum *atype, int *klass_size, int *arg_size)


This file ended up needing a bit of a refactoring as there were some assumptions in place that don't hold when supporting additional intrinsics.
In particular, there are various intrinsics where:
one of the SIMD types may not be generic at all (Vector2, Vector3, Vector4)
multiple generic types exist (As<TFrom, TTo>)
the return type may not be a 128-bit vector (AsVector2, AsVector3)
So, what I did here was I broke this get_common_simd_info method into two:
get_common_simd_info
get_common_simd_scalar_arg
The former now always gets the size of the input klass and secondly determines if it is a SIMD type and what the underlying element type is if so. While the latter identifies the first non-SIMD argument, if one exists.

tannergooding · 2024-06-27T03:33:35Z


 static void
-emit_common_simd_epilogue (TransformData *td, MonoClass *vector_klass, MonoMethodSignature *csignature, int vector_size, gboolean allow_void)
+emit_common_simd_epilogue (TransformData *td, MonoMethodSignature *csignature)


To support methods which return a value type, but where that isn't a 128-bit vector, this explicitly gets the return type from the signature to ensure there can be no accidents

tannergooding · 2024-06-27T03:37:29Z

 	gint16 simd_intrins = -1;

-	vector_klass = mono_class_from_mono_type_internal (csignature->ret);
+	MonoTypeEnum ret_atype;


In here, we consistently query the relevant simd information of the return type and if it exists the simd information of the first parameter (this is enough to correctly handle all the cases that currently exist).
There's actually quite a bit of logic in this function that could be moved down into emit_common_simd_operations, as APIs like AndNot exist for Vector128<T> and Vector<T>, they may also exist for types like Vector4 in the future. I opted to not move that down in this PR, to try and keep the total churn under control.
But, I did add some basic validation that the encountered signatures are roughly as expected to help ensure we don't hit issues in the future as new overloads are introduced or the general SIMD support in Mono is expanded.

tannergooding · 2024-06-28T21:34:30Z

Similarly to #103915, I don't have the time to continue to try and debug why these changes aren't working for Mono.

Anyone should feel free to pick this up if they have more context or time.

-- As it stands, there appears to be some quirk where Mono is either incorrectly doing comparisons or other handling around Vector3 and it's causing most of the downstream failures.

tannergooding · 2024-06-26T16:27:00Z

This should resolvedotnet/perf-autofiling-issues#36484

dotnet-policy-service · 2024-06-26T16:27:27Z

Tagging subscribers to this area: @steveisok, @lambdageek
See info in area-owners.md if you want to be subscribed.

kg · 2024-06-26T19:53:42Z

At a glance this all looks good. If the regression still isn't gone after this on wasm, I can help implement the new intrinsics in the jiterpreter.

tannergooding · 2024-06-26T19:56:39Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

The mono interp handling for AsVector2Single seems to not be quite right though, so I'll see if I can fix that first. Edit: The interp failure was a simple typo

steveisok · 2024-06-26T20:50:06Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

#104028 should make it better. All ios/tvos device runs were failing before this.

tannergooding · 2024-06-26T20:51:58Z

Glad to know it wasn't something on my end, hopefully this is green and can get merged as it should give us some nice improvements 🎉

tannergooding · 2024-06-27T03:32:57Z


 static gboolean
-get_common_simd_info (MonoClass *vector_klass, MonoMethodSignature *csignature, MonoTypeEnum *atype, int *vector_size, int *arg_size, int *scalar_arg)
+get_common_simd_info (MonoClass *klass, MonoTypeEnum *atype, int *klass_size, int *arg_size)


This file ended up needing a bit of a refactoring as there were some assumptions in place that don't hold when supporting additional intrinsics.
In particular, there are various intrinsics where:
one of the SIMD types may not be generic at all (Vector2, Vector3, Vector4)
multiple generic types exist (As<TFrom, TTo>)
the return type may not be a 128-bit vector (AsVector2, AsVector3)
So, what I did here was I broke this get_common_simd_info method into two:
get_common_simd_info
get_common_simd_scalar_arg
The former now always gets the size of the input klass and secondly determines if it is a SIMD type and what the underlying element type is if so. While the latter identifies the first non-SIMD argument, if one exists.

tannergooding · 2024-06-27T03:33:35Z


 static void
-emit_common_simd_epilogue (TransformData *td, MonoClass *vector_klass, MonoMethodSignature *csignature, int vector_size, gboolean allow_void)
+emit_common_simd_epilogue (TransformData *td, MonoMethodSignature *csignature)


To support methods which return a value type, but where that isn't a 128-bit vector, this explicitly gets the return type from the signature to ensure there can be no accidents

tannergooding · 2024-06-27T03:37:29Z

 	gint16 simd_intrins = -1;

-	vector_klass = mono_class_from_mono_type_internal (csignature->ret);
+	MonoTypeEnum ret_atype;


In here, we consistently query the relevant simd information of the return type and if it exists the simd information of the first parameter (this is enough to correctly handle all the cases that currently exist).
There's actually quite a bit of logic in this function that could be moved down into emit_common_simd_operations, as APIs like AndNot exist for Vector128<T> and Vector<T>, they may also exist for types like Vector4 in the future. I opted to not move that down in this PR, to try and keep the total churn under control.
But, I did add some basic validation that the encountered signatures are roughly as expected to help ensure we don't hit issues in the future as new overloads are introduced or the general SIMD support in Mono is expanded.

tannergooding · 2024-06-28T21:34:30Z

Similarly to #103915, I don't have the time to continue to try and debug why these changes aren't working for Mono.

Anyone should feel free to pick this up if they have more context or time.

-- As it stands, there appears to be some quirk where Mono is either incorrectly doing comparisons or other handling around Vector3 and it's causing most of the downstream failures.

tannergooding · 2024-06-26T16:27:00Z

This should resolvedotnet/perf-autofiling-issues#36484

dotnet-policy-service · 2024-06-26T16:27:27Z

Tagging subscribers to this area: @steveisok, @lambdageek
See info in area-owners.md if you want to be subscribed.

kg · 2024-06-26T19:53:42Z

At a glance this all looks good. If the regression still isn't gone after this on wasm, I can help implement the new intrinsics in the jiterpreter.

tannergooding · 2024-06-26T19:56:39Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

The mono interp handling for AsVector2Single seems to not be quite right though, so I'll see if I can fix that first. Edit: The interp failure was a simple typo

steveisok · 2024-06-26T20:50:06Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

#104028 should make it better. All ios/tvos device runs were failing before this.

tannergooding · 2024-06-26T20:51:58Z

Glad to know it wasn't something on my end, hopefully this is green and can get merged as it should give us some nice improvements 🎉

tannergooding · 2024-06-27T03:32:57Z


 static gboolean
-get_common_simd_info (MonoClass *vector_klass, MonoMethodSignature *csignature, MonoTypeEnum *atype, int *vector_size, int *arg_size, int *scalar_arg)
+get_common_simd_info (MonoClass *klass, MonoTypeEnum *atype, int *klass_size, int *arg_size)


This file ended up needing a bit of a refactoring as there were some assumptions in place that don't hold when supporting additional intrinsics.
In particular, there are various intrinsics where:
one of the SIMD types may not be generic at all (Vector2, Vector3, Vector4)
multiple generic types exist (As<TFrom, TTo>)
the return type may not be a 128-bit vector (AsVector2, AsVector3)
So, what I did here was I broke this get_common_simd_info method into two:
get_common_simd_info
get_common_simd_scalar_arg
The former now always gets the size of the input klass and secondly determines if it is a SIMD type and what the underlying element type is if so. While the latter identifies the first non-SIMD argument, if one exists.

tannergooding · 2024-06-27T03:33:35Z


 static void
-emit_common_simd_epilogue (TransformData *td, MonoClass *vector_klass, MonoMethodSignature *csignature, int vector_size, gboolean allow_void)
+emit_common_simd_epilogue (TransformData *td, MonoMethodSignature *csignature)


To support methods which return a value type, but where that isn't a 128-bit vector, this explicitly gets the return type from the signature to ensure there can be no accidents

tannergooding · 2024-06-27T03:37:29Z

 	gint16 simd_intrins = -1;

-	vector_klass = mono_class_from_mono_type_internal (csignature->ret);
+	MonoTypeEnum ret_atype;


In here, we consistently query the relevant simd information of the return type and if it exists the simd information of the first parameter (this is enough to correctly handle all the cases that currently exist).
There's actually quite a bit of logic in this function that could be moved down into emit_common_simd_operations, as APIs like AndNot exist for Vector128<T> and Vector<T>, they may also exist for types like Vector4 in the future. I opted to not move that down in this PR, to try and keep the total churn under control.
But, I did add some basic validation that the encountered signatures are roughly as expected to help ensure we don't hit issues in the future as new overloads are introduced or the general SIMD support in Mono is expanded.

tannergooding · 2024-06-28T21:34:30Z

Similarly to #103915, I don't have the time to continue to try and debug why these changes aren't working for Mono.

Anyone should feel free to pick this up if they have more context or time.

-- As it stands, there appears to be some quirk where Mono is either incorrectly doing comparisons or other handling around Vector3 and it's causing most of the downstream failures.

tannergooding · 2024-06-26T16:27:00Z

This should resolvedotnet/perf-autofiling-issues#36484

dotnet-policy-service · 2024-06-26T16:27:27Z

Tagging subscribers to this area: @steveisok, @lambdageek
See info in area-owners.md if you want to be subscribed.

kg · 2024-06-26T19:53:42Z

At a glance this all looks good. If the regression still isn't gone after this on wasm, I can help implement the new intrinsics in the jiterpreter.

tannergooding · 2024-06-26T19:56:39Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

The mono interp handling for AsVector2Single seems to not be quite right though, so I'll see if I can fix that first. Edit: The interp failure was a simple typo

steveisok · 2024-06-26T20:50:06Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

#104028 should make it better. All ios/tvos device runs were failing before this.

tannergooding · 2024-06-26T20:51:58Z

Glad to know it wasn't something on my end, hopefully this is green and can get merged as it should give us some nice improvements 🎉

tannergooding · 2024-06-27T03:32:57Z


 static gboolean
-get_common_simd_info (MonoClass *vector_klass, MonoMethodSignature *csignature, MonoTypeEnum *atype, int *vector_size, int *arg_size, int *scalar_arg)
+get_common_simd_info (MonoClass *klass, MonoTypeEnum *atype, int *klass_size, int *arg_size)


This file ended up needing a bit of a refactoring as there were some assumptions in place that don't hold when supporting additional intrinsics.
In particular, there are various intrinsics where:
one of the SIMD types may not be generic at all (Vector2, Vector3, Vector4)
multiple generic types exist (As<TFrom, TTo>)
the return type may not be a 128-bit vector (AsVector2, AsVector3)
So, what I did here was I broke this get_common_simd_info method into two:
get_common_simd_info
get_common_simd_scalar_arg
The former now always gets the size of the input klass and secondly determines if it is a SIMD type and what the underlying element type is if so. While the latter identifies the first non-SIMD argument, if one exists.

tannergooding · 2024-06-27T03:33:35Z


 static void
-emit_common_simd_epilogue (TransformData *td, MonoClass *vector_klass, MonoMethodSignature *csignature, int vector_size, gboolean allow_void)
+emit_common_simd_epilogue (TransformData *td, MonoMethodSignature *csignature)


To support methods which return a value type, but where that isn't a 128-bit vector, this explicitly gets the return type from the signature to ensure there can be no accidents

tannergooding · 2024-06-27T03:37:29Z

 	gint16 simd_intrins = -1;

-	vector_klass = mono_class_from_mono_type_internal (csignature->ret);
+	MonoTypeEnum ret_atype;


In here, we consistently query the relevant simd information of the return type and if it exists the simd information of the first parameter (this is enough to correctly handle all the cases that currently exist).
There's actually quite a bit of logic in this function that could be moved down into emit_common_simd_operations, as APIs like AndNot exist for Vector128<T> and Vector<T>, they may also exist for types like Vector4 in the future. I opted to not move that down in this PR, to try and keep the total churn under control.
But, I did add some basic validation that the encountered signatures are roughly as expected to help ensure we don't hit issues in the future as new overloads are introduced or the general SIMD support in Mono is expanded.

tannergooding · 2024-06-28T21:34:30Z

Similarly to #103915, I don't have the time to continue to try and debug why these changes aren't working for Mono.

Anyone should feel free to pick this up if they have more context or time.

-- As it stands, there appears to be some quirk where Mono is either incorrectly doing comparisons or other handling around Vector3 and it's causing most of the downstream failures.

tannergooding · 2024-06-26T16:27:00Z

This should resolvedotnet/perf-autofiling-issues#36484

dotnet-policy-service · 2024-06-26T16:27:27Z

Tagging subscribers to this area: @steveisok, @lambdageek
See info in area-owners.md if you want to be subscribed.

kg · 2024-06-26T19:53:42Z

At a glance this all looks good. If the regression still isn't gone after this on wasm, I can help implement the new intrinsics in the jiterpreter.

tannergooding · 2024-06-26T19:56:39Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

The mono interp handling for AsVector2Single seems to not be quite right though, so I'll see if I can fix that first. Edit: The interp failure was a simple typo

steveisok · 2024-06-26T20:50:06Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

#104028 should make it better. All ios/tvos device runs were failing before this.

tannergooding · 2024-06-26T20:51:58Z

Glad to know it wasn't something on my end, hopefully this is green and can get merged as it should give us some nice improvements 🎉

tannergooding · 2024-06-27T03:32:57Z


 static gboolean
-get_common_simd_info (MonoClass *vector_klass, MonoMethodSignature *csignature, MonoTypeEnum *atype, int *vector_size, int *arg_size, int *scalar_arg)
+get_common_simd_info (MonoClass *klass, MonoTypeEnum *atype, int *klass_size, int *arg_size)


This file ended up needing a bit of a refactoring as there were some assumptions in place that don't hold when supporting additional intrinsics.
In particular, there are various intrinsics where:
one of the SIMD types may not be generic at all (Vector2, Vector3, Vector4)
multiple generic types exist (As<TFrom, TTo>)
the return type may not be a 128-bit vector (AsVector2, AsVector3)
So, what I did here was I broke this get_common_simd_info method into two:
get_common_simd_info
get_common_simd_scalar_arg
The former now always gets the size of the input klass and secondly determines if it is a SIMD type and what the underlying element type is if so. While the latter identifies the first non-SIMD argument, if one exists.

tannergooding · 2024-06-27T03:33:35Z


 static void
-emit_common_simd_epilogue (TransformData *td, MonoClass *vector_klass, MonoMethodSignature *csignature, int vector_size, gboolean allow_void)
+emit_common_simd_epilogue (TransformData *td, MonoMethodSignature *csignature)


To support methods which return a value type, but where that isn't a 128-bit vector, this explicitly gets the return type from the signature to ensure there can be no accidents

tannergooding · 2024-06-27T03:37:29Z

 	gint16 simd_intrins = -1;

-	vector_klass = mono_class_from_mono_type_internal (csignature->ret);
+	MonoTypeEnum ret_atype;


In here, we consistently query the relevant simd information of the return type and if it exists the simd information of the first parameter (this is enough to correctly handle all the cases that currently exist).
There's actually quite a bit of logic in this function that could be moved down into emit_common_simd_operations, as APIs like AndNot exist for Vector128<T> and Vector<T>, they may also exist for types like Vector4 in the future. I opted to not move that down in this PR, to try and keep the total churn under control.
But, I did add some basic validation that the encountered signatures are roughly as expected to help ensure we don't hit issues in the future as new overloads are introduced or the general SIMD support in Mono is expanded.

tannergooding · 2024-06-28T21:34:30Z

Similarly to #103915, I don't have the time to continue to try and debug why these changes aren't working for Mono.

Anyone should feel free to pick this up if they have more context or time.

-- As it stands, there appears to be some quirk where Mono is either incorrectly doing comparisons or other handling around Vector3 and it's causing most of the downstream failures.

tannergooding · 2024-06-26T16:27:00Z

This should resolvedotnet/perf-autofiling-issues#36484

dotnet-policy-service · 2024-06-26T16:27:27Z

Tagging subscribers to this area: @steveisok, @lambdageek
See info in area-owners.md if you want to be subscribed.

kg · 2024-06-26T19:53:42Z

At a glance this all looks good. If the regression still isn't gone after this on wasm, I can help implement the new intrinsics in the jiterpreter.

tannergooding · 2024-06-26T19:56:39Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

The mono interp handling for AsVector2Single seems to not be quite right though, so I'll see if I can fix that first. Edit: The interp failure was a simple typo

steveisok · 2024-06-26T20:50:06Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

#104028 should make it better. All ios/tvos device runs were failing before this.

tannergooding · 2024-06-26T20:51:58Z

Glad to know it wasn't something on my end, hopefully this is green and can get merged as it should give us some nice improvements 🎉

tannergooding · 2024-06-27T03:32:57Z


 static gboolean
-get_common_simd_info (MonoClass *vector_klass, MonoMethodSignature *csignature, MonoTypeEnum *atype, int *vector_size, int *arg_size, int *scalar_arg)
+get_common_simd_info (MonoClass *klass, MonoTypeEnum *atype, int *klass_size, int *arg_size)


This file ended up needing a bit of a refactoring as there were some assumptions in place that don't hold when supporting additional intrinsics.
In particular, there are various intrinsics where:
one of the SIMD types may not be generic at all (Vector2, Vector3, Vector4)
multiple generic types exist (As<TFrom, TTo>)
the return type may not be a 128-bit vector (AsVector2, AsVector3)
So, what I did here was I broke this get_common_simd_info method into two:
get_common_simd_info
get_common_simd_scalar_arg
The former now always gets the size of the input klass and secondly determines if it is a SIMD type and what the underlying element type is if so. While the latter identifies the first non-SIMD argument, if one exists.

tannergooding · 2024-06-27T03:33:35Z


 static void
-emit_common_simd_epilogue (TransformData *td, MonoClass *vector_klass, MonoMethodSignature *csignature, int vector_size, gboolean allow_void)
+emit_common_simd_epilogue (TransformData *td, MonoMethodSignature *csignature)


To support methods which return a value type, but where that isn't a 128-bit vector, this explicitly gets the return type from the signature to ensure there can be no accidents

tannergooding · 2024-06-27T03:37:29Z

 	gint16 simd_intrins = -1;

-	vector_klass = mono_class_from_mono_type_internal (csignature->ret);
+	MonoTypeEnum ret_atype;


In here, we consistently query the relevant simd information of the return type and if it exists the simd information of the first parameter (this is enough to correctly handle all the cases that currently exist).
There's actually quite a bit of logic in this function that could be moved down into emit_common_simd_operations, as APIs like AndNot exist for Vector128<T> and Vector<T>, they may also exist for types like Vector4 in the future. I opted to not move that down in this PR, to try and keep the total churn under control.
But, I did add some basic validation that the encountered signatures are roughly as expected to help ensure we don't hit issues in the future as new overloads are introduced or the general SIMD support in Mono is expanded.

tannergooding · 2024-06-28T21:34:30Z

Similarly to #103915, I don't have the time to continue to try and debug why these changes aren't working for Mono.

Anyone should feel free to pick this up if they have more context or time.

-- As it stands, there appears to be some quirk where Mono is either incorrectly doing comparisons or other handling around Vector3 and it's causing most of the downstream failures.

tannergooding · 2024-06-26T16:27:00Z

This should resolvedotnet/perf-autofiling-issues#36484

dotnet-policy-service · 2024-06-26T16:27:27Z

Tagging subscribers to this area: @steveisok, @lambdageek
See info in area-owners.md if you want to be subscribed.

kg · 2024-06-26T19:53:42Z

At a glance this all looks good. If the regression still isn't gone after this on wasm, I can help implement the new intrinsics in the jiterpreter.

tannergooding · 2024-06-26T19:56:39Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

The mono interp handling for AsVector2Single seems to not be quite right though, so I'll see if I can fix that first. Edit: The interp failure was a simple typo

steveisok · 2024-06-26T20:50:06Z

I'm not sure why ios-arm64 and tvos-arm64 are failing, I've seen this on a couple Mono PRs that are touching fairly different areas so far

#104028 should make it better. All ios/tvos device runs were failing before this.

tannergooding · 2024-06-26T20:51:58Z

Glad to know it wasn't something on my end, hopefully this is green and can get merged as it should give us some nice improvements 🎉

tannergooding · 2024-06-27T03:32:57Z


 static gboolean
-get_common_simd_info (MonoClass *vector_klass, MonoMethodSignature *csignature, MonoTypeEnum *atype, int *vector_size, int *arg_size, int *scalar_arg)
+get_common_simd_info (MonoClass *klass, MonoTypeEnum *atype, int *klass_size, int *arg_size)


This file ended up needing a bit of a refactoring as there were some assumptions in place that don't hold when supporting additional intrinsics.
In particular, there are various intrinsics where:
one of the SIMD types may not be generic at all (Vector2, Vector3, Vector4)
multiple generic types exist (As<TFrom, TTo>)
the return type may not be a 128-bit vector (AsVector2, AsVector3)
So, what I did here was I broke this get_common_simd_info method into two:
get_common_simd_info
get_common_simd_scalar_arg
The former now always gets the size of the input klass and secondly determines if it is a SIMD type and what the underlying element type is if so. While the latter identifies the first non-SIMD argument, if one exists.

tannergooding · 2024-06-27T03:33:35Z


 static void
-emit_common_simd_epilogue (TransformData *td, MonoClass *vector_klass, MonoMethodSignature *csignature, int vector_size, gboolean allow_void)
+emit_common_simd_epilogue (TransformData *td, MonoMethodSignature *csignature)


To support methods which return a value type, but where that isn't a 128-bit vector, this explicitly gets the return type from the signature to ensure there can be no accidents

tannergooding · 2024-06-27T03:37:29Z

 	gint16 simd_intrins = -1;

-	vector_klass = mono_class_from_mono_type_internal (csignature->ret);
+	MonoTypeEnum ret_atype;


In here, we consistently query the relevant simd information of the return type and if it exists the simd information of the first parameter (this is enough to correctly handle all the cases that currently exist).
There's actually quite a bit of logic in this function that could be moved down into emit_common_simd_operations, as APIs like AndNot exist for Vector128<T> and Vector<T>, they may also exist for types like Vector4 in the future. I opted to not move that down in this PR, to try and keep the total churn under control.
But, I did add some basic validation that the encountered signatures are roughly as expected to help ensure we don't hit issues in the future as new overloads are introduced or the general SIMD support in Mono is expanded.

tannergooding · 2024-06-28T21:34:30Z

Similarly to #103915, I don't have the time to continue to try and debug why these changes aren't working for Mono.

Anyone should feel free to pick this up if they have more context or time.

-- As it stands, there appears to be some quirk where Mono is either incorrectly doing comparisons or other handling around Vector3 and it's causing most of the downstream failures.

tannergooding requested a review from fanyang-mono as a code owner June 26, 2024 16:27

ghost added the area-Codegen-meta-mono label Jun 26, 2024

dotnet-policy-serviceBot assigned tannergooding Jun 26, 2024

tannergooding requested review from BrzVlad and kotlarmilos as code owners June 26, 2024 16:35

tannergooding commented Jun 26, 2024
View reviewed changes

Comment threadsrc/mono/mono/mini/interp/transform-simd.c Outdated

tannergooding force-pushed the mono-vectoras branch from 3d8a019 to 434ff3dCompare June 27, 2024 03:25

tannergooding commented Jun 27, 2024
View reviewed changes

tannergooding force-pushed the mono-vectoras branch 3 times, most recently from 742333c to f35dd63Compare June 27, 2024 05:45

tannergooding marked this pull request as draft June 27, 2024 05:56

tannergooding force-pushed the mono-vectoras branch from f35dd63 to 4cd5d90Compare June 27, 2024 06:50

tannergooding force-pushed the mono-vectoras branch from 4cd5d90 to e4a14fbCompare June 27, 2024 14:28

tannergooding force-pushed the mono-vectoras branch 3 times, most recently from 09ee415 to 1d03cbdCompare June 28, 2024 16:04

Update Mono to handle various other vector bitcast APIs
8b0b476

tannergooding force-pushed the mono-vectoras branch from 1d03cbd to 8b0b476Compare June 28, 2024 17:13

tannergooding closed this Jun 28, 2024

tannergooding reopened this Jun 28, 2024

tannergooding closed this Jun 28, 2024

tannergooding mentioned this pull request Jul 1, 2024
Update mono-interp to handle the same Vector.As APIs as mono-jit #104217
Merged

github-actionsBot locked and limited conversation to collaborators Jul 29, 2024

tannergooding deleted the mono-vectoras branch July 1, 2025 14:40