The issue is mostly that we suck more on Spec2k6 than we realized. Since publishing that paper we do track Spec2k6 internally but we don't spend time tuning for it.
/v8 wasm runtime TL
The issue is mostly that we suck more on Spec2k6 than we realized. Since publishing that paper we do track Spec2k6 internally but we don't spend time tuning for it.
/v8 wasm runtime TL
1. WASM <--> JS/Host calls seem to have a higher cost on chrome than FF [1][2]. Is that in your optimization roadmap?
2. Wasmer tracks V8 perf against other backbends, and the LLVM backend consistently outperforms V8 [3]. Can anything be done to address this, especially for node, where the compile time cost of a super optimizing compiler might be beneficial in certain applications?
[1]: https://bnjbvr.github.io/perf-wasm-calls/
[2]: https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
The code in lines 35-37 in Figure 7(c) looks like you should be able to fold the memory operand even in a simple peephole pass before register allocation, no? (I know, I know, patches are probably welcome ;-))