Wasmi uses the wasmparser crate for parsing and validating Wasm bytecode.
Furthermore, Wasmi uses wasmparser's visit_operator API since it is slightly more efficient.
However, this has one very big consequence for Wasmi's parsing infrastructure:
There is no way to peek the next Wasm operator. The only thing we can do is to look-behind which we did with the rather complex staged Op design.
Having the ability to look-ahead (instead of look-behind) parsing would allow us to avoid more unnecessary spills and generate slightly better Wasmi IR in some situations. Furthermore it would simplify implementation of features like #1889.
It is unknown whether it is possible to implement this with the current architecture and how much we'd need to change Wasmi's parsing infrastructure. Ideally we could keep the visit_operator API from wasmparser.
Wasmi uses the
wasmparsercrate for parsing and validating Wasm bytecode.Furthermore, Wasmi uses
wasmparser'svisit_operatorAPI since it is slightly more efficient.However, this has one very big consequence for Wasmi's parsing infrastructure:
There is no way to peek the next Wasm operator. The only thing we can do is to look-behind which we did with the rather complex staged
Opdesign.Having the ability to look-ahead (instead of look-behind) parsing would allow us to avoid more unnecessary spills and generate slightly better Wasmi IR in some situations. Furthermore it would simplify implementation of features like #1889.
It is unknown whether it is possible to implement this with the current architecture and how much we'd need to change Wasmi's parsing infrastructure. Ideally we could keep the
visit_operatorAPI fromwasmparser.