Blocked by #1734.
With #1734 implemented all executor cells are fixed 64-bits wide.
When loading or storing 32-bit (or 8-bit, 16-bit, etc..) values from and to those cells the whole 64-bits are always read or written which is somewhat wasteful.
For reads we would ideally only load from the lower 32-bits of the 64-bit cell.
For stores we would ideally only store the lower 32-bits of the 64-bit cell.
- Implementing variable-width reads should trivial and yield no major complications.
- Implementing variable-width writes might be tricky and introduce intricate issues.
- We might need special variants of certain instructions to read only lower bits because writing only lower bits might not set upper bits to zero which in turn might invalidate results if other general instructions still read all bits when only parts of the bits are needed. An example for this is
global.{get,set}. If we implement variable-width writes we'd need both global.get32 and global.get64 to counteract this issue. Same with select and certain other general instructions.
It is not clear whether this optimization actually improves performance or just complicates Wasmi's bytecode and executor.
Blocked by #1734.
With #1734 implemented all executor cells are fixed 64-bits wide.
When loading or storing 32-bit (or 8-bit, 16-bit, etc..) values from and to those cells the whole 64-bits are always read or written which is somewhat wasteful.
For reads we would ideally only load from the lower 32-bits of the 64-bit cell.
For stores we would ideally only store the lower 32-bits of the 64-bit cell.
global.{get,set}. If we implement variable-width writes we'd need bothglobal.get32andglobal.get64to counteract this issue. Same withselectand certain other general instructions.It is not clear whether this optimization actually improves performance or just complicates Wasmi's bytecode and executor.