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_regandset_pinned_reginstructions) 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 theregisterkeyword 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!
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_regandset_pinned_reginstructions) 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 theregisterkeyword 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!
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_regandset_pinned_reginstructions) 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 theregisterkeyword 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!
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