[wasm][interp] alias Vector operators to PackedSimd

[lewing]

Testing the behavior for the moment, help welcome.

[kg]

I kind of wish we could do this in managed instead, so that both the mono interpreter and mono aot would automatically benefit from it. And then if ryujit ever learns to generate wasm in the future, it'll also forward to packedsimd there.
I don't love that we're growing even more complexity in the interpreter's simd implementation.

[lewing]

I kind of wish we could do this in managed instead, so that both the mono interpreter and mono aot would automatically benefit from it. And then if ryujit ever learns to generate wasm in the future, it'll also forward to packedsimd there. I don't love that we're growing even more complexity in the interpreter's simd implementation.

The same logic is happening there (see previous fixes), I just limited scope for the moment. I'm trying to stage the work in measurable chunks because I'm using my personal time here. My goal is to land all the AOT improvements eventually too.

[kg]

I kind of wish we could do this in managed instead, so that both the mono interpreter and mono aot would automatically benefit from it. And then if ryujit ever learns to generate wasm in the future, it'll also forward to packedsimd there. I don't love that we're growing even more complexity in the interpreter's simd implementation.

The same logic is happening there (see previous fixes), I just limited scope for the moment. I'm trying to stage the work in measurable chunks because I'm using my personal time here. My goal is to land all the AOT improvements eventually too.

What I mean is, could we do the equivalent of this, and just have PackedSimd arms for all of the relevant methods in C#:

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Vector128.cs

Lines 359 to 370 in c08ef4b

	public static unsafe Vector128<double> ConvertToDouble(Vector128<long> vector)
	{
	if (Sse2.IsSupported)
	{
	// Based on __m256d int64_to_double_fast_precise(const __m256i v)
	// from https://stackoverflow.com/a/41223013/12860347. CC BY-SA 4.0
	Vector128<int> lowerBits;
	if (Avx2.IsSupported)
	{
	lowerBits = vector.AsInt32();

Then interp and aot and any other future codegen implementations will just light up as long as the method is inlined.

I don't know if the code owners for SRI and SNV have feelings on this. It feels like asking a lot of your team to maintain a bunch of manual intrinsics implementations for SRI and SNV in both AOT and interp and jiterpreter. And I don't know how NativeAOT-LLVM wasm handles this, for that matter.

[lewing]

I kind of wish we could do this in managed instead, so that both the mono interpreter and mono aot would automatically benefit from it. And then if ryujit ever learns to generate wasm in the future, it'll also forward to packedsimd there. I don't love that we're growing even more complexity in the interpreter's simd implementation.

The same logic is happening there (see previous fixes), I just limited scope for the moment. I'm trying to stage the work in measurable chunks because I'm using my personal time here. My goal is to land all the AOT improvements eventually too.

What I mean is, could we do the equivalent of this, and just have PackedSimd arms for all of the relevant methods in C#:

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Vector128.cs

Lines 359 to 370 in c08ef4b

	public static unsafe Vector128<double> ConvertToDouble(Vector128<long> vector)
	{
	if (Sse2.IsSupported)
	{
	// Based on __m256d int64_to_double_fast_precise(const __m256i v)
	// from https://stackoverflow.com/a/41223013/12860347. CC BY-SA 4.0
	Vector128<int> lowerBits;
	if (Avx2.IsSupported)
	{
	lowerBits = vector.AsInt32();

Then interp and aot and any other future codegen implementations will just light up as long as the method is inlined.

I don't know if the code owners for SRI and SNV have feelings on this. It feels like asking a lot of your team to maintain a bunch of manual intrinsics implementations for SRI and SNV in both AOT and interp and jiterpreter. And I don't know how NativeAOT-LLVM wasm handles this, for that matter.

There is a huge amount of space to share interpreter and native SIMD ops here and in the future with other EEs. For the moment I'm just connecting the existing intrisics on the wasm interpreter for net10 (and a little to make point for future implementations).

[lewing]

I will probably separate the isimd changes back out of this, they should be a win without resolving the other failures.

[lewing]

/ba-g failures are known