[wasm] Optimize constant i2/i4 shuffles in jiterpreter

[kg]

(draft because blocked by #86469)
For known-constant shuffle vectors, the jiterpreter can transform the i2/i4 indices into a byte shuffle vector at JIT time and encode it directly into the trace. In my testing this speeds up span Reverse on chars a bit. Not sure if it's a good idea to do this, so feedback is appreciated.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

(draft because blocked by #86469)
For known-constant shuffle vectors, the jiterpreter can transform the i2/i4 indices into a byte shuffle vector at JIT time and encode it directly into the trace. In my testing this speeds up span Reverse on chars a bit. Not sure if it's a good idea to do this, so feedback is appreciated.

Author:	kg
Assignees:	-
Labels:	arch-wasm, area-Codegen-Jiterpreter-mono
Milestone:	-

[kg]

@BrzVlad @kotlarmilos How do you feel about optimizing the constant shuffles this way? It seems like it might be best to do this in interp, but it's not clear to me how much work it would be to do the analysis there. The jiterpreter would still need to do the lowering, since on the C side and on non-wasm platforms we still want to generate the opcodes for I2/I4 shuffle. So the jiterp would need some way to know that the indices are constant and know what the indices are.

The relevant part of reverse chars looks like this:

dotnet.runtime.js:3 MONO_WASM: 326a0fc ldobj.vt 96 -> 128
dotnet.runtime.js:3 MONO_WASM: 326a104 simd_v128_ldc  -> 160
dotnet.runtime.js:3 MONO_WASM: 326a118 V128_I2_SHUFFLE 112, 160 -> 112
dotnet.runtime.js:3 MONO_WASM: 326a122 simd_v128_ldc  -> 160
dotnet.runtime.js:3 MONO_WASM: 326a136 V128_I2_SHUFFLE 128, 160 -> 128
dotnet.runtime.js:3 MONO_WASM: 326a140 stobj.vt.noref 88, 128
dotnet.runtime.js:3 MONO_WASM: 326a148 stobj.vt.noref 96, 112

Maybe we could define new SHUFFLE_CONSTANT opcodes that the jiterp consumes, and generate them by doing a peephole optimization?

[kg]

Rebasing onto #86506 since there would be a merge conflict. Timings with both applied:

measurement	main	#86506	both PRs
Span, Reverse bytes	0.0213ms	0.0139ms	0.0126ms
Span, Reverse chars	0.0418ms	0.0256ms	0.0228ms

EDIT: I'll note that from reading v8's source code, they have optimizations that kick in when they can detect a constant indices vector, so it makes sense that we see a speedup here.

[BrzVlad]

I strongly suggest any kind of constant tracking to be done within the interpreter.

[kg]

I strongly suggest any kind of constant tracking to be done within the interpreter.

OK. I'll leave this no merge until we figure out how we want to handle it, and we can remove the other constant tracking when we do that.

[kg]

My recollection of the conversations I've had about this is as follows:

• We want to heavily limit how much the jiterpreter does this category of optimization, but narrowly scoped cases like this (the immediate is from a preceding opcode) are OK
• In the future we want to introduce a variant of the SIMD opcodes that accepts an immediate - we need it for ExtractLane/ReplaceLane anyway, so it would be natural to apply it to this case as well
• Once we have 'immediate' SIMD opcodes, we can introduce immediate versions of shuffle and then the jiterpreter can be updated to consume those opcodes instead of detecting the constant shuffle itself
  I'll probably rebase this soon and land it since I'm not aware of any reason to block it at present.