Stream: git-wasmtime

Topic: wasmtime / issue #3312 Make use of pinned register for vm...


view this post on Zulip Wasmtime GitHub notifications bot (Sep 07 2021 at 22:32):

cfallin opened issue #3312:

We currently have special support for exactly one "pinned register" in CLIF, and this is used by the SpiderMonkey bindings to Cranelift in order to ensure that the VM context pointer always remains accessible in a register. cHowever, the Wasmtime code translation does not make use of the pinned register, or provide register-allocator hints in general, to allow the backend to handle the VM-context pointer or heap base pointer in any specially-optimized way.

I was reminded in a recent conversation of this, and it is still an open opportunity. We could either use the pinned register as-is (with get_pinned_reg and set_pinned_reg instructions) or, perhaps once we've moved over to regalloc2, develop a more general sort of metadata/hint that indicates that certain values are long-lived. (Something like the register keyword that used to mean something to C compilers.) Perhaps the regalloc heuristics are good enough to work this out in many cases, but perhaps they aren't, and we can save some work; we should study the issue to be sure.

This might make a good starter issue for someone looking to get into the codegen/backends, and can range from relatively simple (use existing pinned-reg infra) to more general; I'm happy to help describe more detail if so!

view this post on Zulip Wasmtime GitHub notifications bot (Sep 07 2021 at 22:32):

cfallin labeled issue #3312:

We currently have special support for exactly one "pinned register" in CLIF, and this is used by the SpiderMonkey bindings to Cranelift in order to ensure that the VM context pointer always remains accessible in a register. cHowever, the Wasmtime code translation does not make use of the pinned register, or provide register-allocator hints in general, to allow the backend to handle the VM-context pointer or heap base pointer in any specially-optimized way.

I was reminded in a recent conversation of this, and it is still an open opportunity. We could either use the pinned register as-is (with get_pinned_reg and set_pinned_reg instructions) or, perhaps once we've moved over to regalloc2, develop a more general sort of metadata/hint that indicates that certain values are long-lived. (Something like the register keyword that used to mean something to C compilers.) Perhaps the regalloc heuristics are good enough to work this out in many cases, but perhaps they aren't, and we can save some work; we should study the issue to be sure.

This might make a good starter issue for someone looking to get into the codegen/backends, and can range from relatively simple (use existing pinned-reg infra) to more general; I'm happy to help describe more detail if so!

view this post on Zulip Wasmtime GitHub notifications bot (Sep 07 2021 at 22:32):

cfallin edited issue #3312:

We currently have special support for exactly one "pinned register" in CLIF, and this is used by the SpiderMonkey bindings to Cranelift in order to ensure that the VM context pointer always remains accessible in a register. However, the Wasmtime code translation does not make use of the pinned register, or provide register-allocator hints in general, to allow the backend to handle the VM-context pointer or heap base pointer in any specially-optimized way.

I was reminded in a recent conversation of this, and it is still an open opportunity. We could either use the pinned register as-is (with get_pinned_reg and set_pinned_reg instructions) or, perhaps once we've moved over to regalloc2, develop a more general sort of metadata/hint that indicates that certain values are long-lived. (Something like the register keyword that used to mean something to C compilers.) Perhaps the regalloc heuristics are good enough to work this out in many cases, but perhaps they aren't, and we can save some work; we should study the issue to be sure.

This might make a good starter issue for someone looking to get into the codegen/backends, and can range from relatively simple (use existing pinned-reg infra) to more general; I'm happy to help describe more detail if so!

view this post on Zulip Wasmtime GitHub notifications bot (Sep 08 2021 at 07:34):

bnjbvr commented on issue #3312:

Thanks for opening an issue! I think that's a very low hanging fruit, as using the pinned register for e.g. the heap base would have a tremendous impact in terms of reducing the amount of CLIF nodes, thus the number of VCode insts, thus speeding up regalloc.


Last updated: Jan 10 2026 at 20:04 UTC