Use Wasm globals instead of `StgRegTable` for Cmm global registers
Is your feature request related to a problem? Please describe.
In the current codegen, we translate loads/stores of Cmm global registers to loads/stores in the StgRegTable field in MainCapability, which later become loads/stores to constant memory locations. This is similar to the unregisterised native backend, being simple to implement, and we can track the loads/stores of global registers using the existing memory trap feature.
It is possible to use wasm globals to implement Cmm global registers though, and it can potentially benefit the runtime performance of Cmm code. In order to have a quantitative measurement about that, this issue should be looked at only after #640 is completed.
Describe the solution you'd like
- [ ] Always include the Wasm globals for Cmm global registers in the linker output. It is possible to use gc-sections to eliminate unneeded globals just like functions, but the yak level is a bit high I think.
- [ ] Modify the codegen to use Wasm globals for Cmm global registers.
- [ ] The JavaScript runtime may need to interop with certain global registers (e.g.
R1), so modify those places as well. Even though the mutable globals proposal is already switched on by default in major platforms, we're dealing withi64globals here, so we need to expose getter/setter functions instead. - [ ] Run
nofibperformance testing to get quantitative measure about whether this results in performance improvement, and if so, how much. It's possible that the originalStgRegTableimplementation is superior though, but the work about this issue shall still be meaningful research to be conducted.