-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wasm] Complete interp PackedSimd support and expand jiterp support #87903
Conversation
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsThis draft PR will add support for the missing PackedSimd intrinsics that require constants. Right now it only implements ExtractLane and ReplaceLane, and the jiterpreter doesn't handle the new opcodes. Depends on #87719.
|
Revised based on feedback from Vlad. Much simpler now. Also added jiterp support. |
Custom PackedSimd.Shuffle in jiterp Simplify definition of intrinsics with custom C implementations Clean up dummy interp dregs Many other commits squashed
Since the cla check hung and there is no option to re-run it I rebased the PR onto main to hopefully trigger the checks again. |
This PR completes interpreter support for WASM PackedSimd and adds jiterpreter support for most of the intrinsics. I had to make significant changes to how the intrinsics are defined and overhaul transform-simd's PackedSimd code to make it all work, so there's a lot of stuff in here that probably is wrong or needs to be adjusted.
Key points:
INTERP_WASM_SIMD_INTRINSIC_V_xxx
defines a WASM-only interp simd intrinsic that is auto-generated to wrap a given compiler intrinsic. It also specifies the binary encoding of the wasm operation, which jiterp will use during code generation. The vast majority of the PackedSimd intrinsics are defined this way.INTERP_WASM_SIMD_INTRINSIC_V_Cx
defines a WASM-only interp simd intrinsic that is hand-written in C like the regular SIMD intrinsics. Most of these have special implementations in jiterp, and they tend to have weird calling conventions (like accepting constant parameter values or pointers).Store
and its siblings) have a void return type; I handle them as if they have a return type and I just never write to the dreg. This is probably incorrect, but it wasn't clear to me how it should actually work so I left it as-is.public static unsafe Vector128<float> LoadScalarVector128(float* address)
will match the entryINTERP_WASM_SIMD_INTRINSIC_V_C1 (LoadScalarVector128, X4, interp_packedsimd_load32_zero, 0x5c)
because the type criteriaX4
means 'any 4-byte type';static uint ExtractLane(Vector128<byte> value, [ConstantExpected(Max = (byte)(15))] byte index)
will matchINTERP_WASM_SIMD_INTRINSIC_V_C2 (ExtractLane, U1, interp_packedsimd_extractlane_u1, 0x16)
due to theU1
type criteria.Expands on #87719 (and currently contains its changes since it hasn't passed review; maybe this should just replace it.)