-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Closed
Labels
area-VM-coreclros-browserBrowser variant of arch-wasmBrowser variant of arch-wasmruntime-coreclrspecific to the CoreCLR runtimespecific to the CoreCLR runtime
Milestone
Description
Helper call opcodes
We need to handle interpreter helper call opcodes like INTOP_CALL_HELPER_P_G differently for wasm, as we don't have real precode stubs. The proof of concept code updated few these opcodes to call the managed helper calls directly on wasm. The updated INTOP_CALL_HELPER_P_G opcode exec part looks like this:
+ MethodDesc *pILTargetMethod;
+ HELPER_FTN_P_P helperFtn = GetPossiblyIndirectHelper<HELPER_FTN_P_P>(pMethod, ip[3], &pILTargetMethod);
+ printf("helperFtn: %p, helperArg: %p pIL: %p\n", helperFtn, helperArg, pILTargetMethod);
+ if (pILTargetMethod != nullptr) {
+ returnOffset = ip[1];
+ int stackOffset = pMethod->allocaSize;
+ callArgsOffset = stackOffset;
+
+ LOCAL_VAR(stackOffset, void*) = helperArg;
+
+ targetMethod = pILTargetMethod;
+ ip += 5;
+ goto CALL_INTERP_METHOD;
+ }
...
The intention is to later extend that to other platforms too to avoid calling the interpreter again through the stubs and instead continue the interp exec main loop when possible.
Done actions
-
discuss the current approach with others to make sure it is the right direction
-
also look at tiering, it is now disabled for wasm as it was breaking this approach, find out whether it makes sense in our case and how to fix it
Current next steps
- update all the helper call opcodes, there should be cca 14 of them
Metadata
Metadata
Assignees
Labels
area-VM-coreclros-browserBrowser variant of arch-wasmBrowser variant of arch-wasmruntime-coreclrspecific to the CoreCLR runtimespecific to the CoreCLR runtime
Type
Projects
Status
No status