7bd61b601c
Some instructions in WebAssembly trap for some inputs, which means that the execution is terminated and (at least at the moment) a JavaScript exception is thrown. Examples for traps are out-of-bounds memory accesses, or integer divisions by zero. Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5 TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position constant), in addition to the trap condition itself. Additionally, each WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose number of inputs is linear to the number of trap checks in the function. Especially for functions with high numbers of trap checks we observe a significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing a TrapIf common operator only a single node is necessary per trap check, in addition to the trap condition. Also the nodes which are shared between trap checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a speedup of 30-50% on average. This CL only implements TrapIf and TrapUnless on x64. The implementation is also hidden behind the --wasm-trap-if flag. Please take a special look at how the source position is transfered from the instruction selector to the code generator, and at the context that is used for the runtime call. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2562393002 Cr-Commit-Position: refs/heads/master@{#41720} |
||
---|---|---|
.. | ||
OWNERS | ||
test-managed.cc | ||
test-run-wasm-64.cc | ||
test-run-wasm-asmjs.cc | ||
test-run-wasm-interpreter.cc | ||
test-run-wasm-js.cc | ||
test-run-wasm-module.cc | ||
test-run-wasm-relocation.cc | ||
test-run-wasm-simd-lowering.cc | ||
test-run-wasm-simd.cc | ||
test-run-wasm.cc | ||
test-wasm-stack.cc | ||
test-wasm-trap-position.cc | ||
wasm-run-utils.h |