[mono][interp] Remove dependence on svar/dvar when computing call offset #81017
Conversation
On optimized code, we made sure we always had a svar set, even if the call had no args. We then resolved the offset of the call as the offset of the first arg. On unoptimized code, we made sure we always had a dvar set, even if the call has void return. We then resolved the offset of the call as the offset of the dvar. As we are introducing alignment guarantees of param area and, in the future, the dvar (only if it is simd type), the offset of the dvar and svar can end up with quite different offsets. This commit solves these complications by introducing a call_offset field in the call info data, which represents the offset of the call args. This field is set either by the var offset allocator or on the fly, during compilation, in unoptimized case. The dvar offset is allocated independently and when emitting compacted instruction for calls, we do it now in an unified way between optimized and unoptimized compilation.
|
Tagging subscribers to this area: @BrzVlad Issue DetailsOn optimized code, we made sure we always had a svar set, even if the call had no args. We then resolved the offset of the call as the offset of the first arg. This commit solves these complications by introducing a call_offset field in the call info data, which represents the offset of the call args. This field is set either by the var offset allocator in optimized case or on the fly, during compilation, in unoptimized case. The dvar offset is allocated independently. When emitting compacted instruction for calls, we do it now in an unified way between optimized and unoptimized compilation, by offsetting
|
|
/azp run runtime-wasm |
|
/azp run runtime-wasm-libtests |
|
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
|
Azure Pipelines successfully started running 1 pipeline(s). |
| @@ -147,11 +147,12 @@ struct _InterpCallInfo { | |||
| // in the order they are pushed to the stack. This makes it easy to find | |||
| // all source vars for these types of opcodes. This is terminated with -1. | |||
| int *call_args; | |||
| int call_offset; | |||
There was a problem hiding this comment.
call_end_offset has become temporary variable needed only during the offset allocation and it might be removed from the call_info struct.
There was a problem hiding this comment.
We added the call_end_offset field so we can easily map between call InterpInst to allocated offset, without use of other data structures and lookups. Did you have an alternative for this ?
There was a problem hiding this comment.
Without other data structures, no. It can be inferred from base_offset + call_args but it is probably inefficient.
I would agree. There is certain room for refactoring in general, we can think about it in the future. |
Assumption that return offset is identical to location of param offset for this opcode is no longer true. Set the param_offset explicitly, separate from the return, similar to dotnet#81017
* [mono][interp] Remove unused method * [mono][interp] Optimize code just in case * [mono][interp] Align simd types to 16 bytes by default All interp vars (args, il locals and other allocated vars) are now aligned to 16 byte offsets. * [mono][interp] Add svar arg to MINT_NEWOBJ_SLOW_UNOPT Assumption that return offset is identical to location of param offset for this opcode is no longer true. Set the param_offset explicitly, separate from the return, similar to #81017 * [mono][interp] Disable assertion on hot path * [mono][interp] Remove some duplicate code
ghost
locked as resolved and limited conversation to collaborators
On optimized code, we made sure we always had a svar set, even if the call had no args. We then resolved the offset of the call as the offset of the first arg.
On unoptimized code, we made sure we always had a dvar set, even if the call has void return. We then resolved the offset of the call as the offset of the dvar. As we are introducing alignment guarantees of param area and, in the future, the dvar (only if it is simd type), the offset of the dvar and svar can end up with quite different offsets.
This commit solves these complications by introducing a call_offset field in the call info data, which represents the offset of the call args. This field is set either by the var offset allocator in optimized case or on the fly, during compilation, in unoptimized case. The dvar offset is allocated independently. When emitting compacted instruction for calls, we do it now in an unified way between optimized and unoptimized compilation, by offsetting
call_offsetfromtd->param_area_offset, which is now initialized in both modes.