Update Mono to handle various other vector bitcast APIs

[tannergooding]

This should resolve dotnet/perf-autofiling-issues#36484

[dotnet-policy-service]

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

[kg]

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]

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]

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]

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]

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]

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]

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]

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.