asterius icon indicating copy to clipboard operation
asterius copied to clipboard

Use Wasm globals instead of `StgRegTable` for Cmm global registers

Open TerrorJack opened this issue 5 years ago • 0 comments

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 with i64 globals here, so we need to expose getter/setter functions instead.
  • [ ] Run nofib performance testing to get quantitative measure about whether this results in performance improvement, and if so, how much. It's possible that the original StgRegTable implementation is superior though, but the work about this issue shall still be meaningful research to be conducted.

TerrorJack avatar May 16 '20 13:05 TerrorJack