Hi Paolo, > What is the performance of lowered 64-bit vs. the TCG_VADDR_BITS > approach?
For comparison, I ran a gzip compression on 500KB data using an x86_64 guest [1]. The TCG_VADDR_BITS approach was 1.14 faster than with -sMEMORY64=2 (approximately 18.8 s vs 21.4 s). > Also, Emscripten's -sMEMORY64=2 is okay for TCI but it would > not work for TCG; you'd still need TCG_VADDR_BITS to be able to produce > wasm32 at runtime, which makes -sMEMORY64=2 only a stopgap. Yes, the Wasm TCG backend needs to be aware of the target host configuration (i.e. -sMEMORY64=1 or 2) so the current Wasm TCG patch set [2] propagates -sMEMORY64 value to the TCG backend via a macro. > So I think we should go for TCG_VADDR_BITS anyway. It's surprisingly > *un*invasive. > > I assume wasm32 has CONFIG_ATOMIC64? It has CONFIG_ATOMIC64. [1] https://github.com/ktock/qemu-wasm/actions/runs/20913930555/job/60082798942#step:4:14 [2] https://patchew.org/QEMU/[email protected]/a507277f4b40617655ba1c94963ef42c78ebbcca.1756724464.git.ktokunaga.m...@gmail.com/ Regards, Kohei
