alexcrichton opened PR #7162 from alexcrichton:rv64-use-zero-reg to bytecodealliance:main:
This commit is an attempt to use the
zeroregister more often in the riscv64 backend. Currently materializing aniconst 0value moves thezeroregister into a general purpose register, and then the general purpose register is used. This means that an extra register is used when it doesn't need to be, for example.Naively fixing this by returning
(zero_reg)during constant emission does not work. One reason this doesn't work is that it introduces vcode aliases to the physical register 0, and duringOperandCollectorcollection the physical register makes its way into normal constraints rather than being a fixed nonallocatable constraint. This is fixable by moving the "resolve alias" phase earlier, for example at the beginning ofreg_userather than lower down inadd_operand.Even after applying such a fix, however, that solution still does not work. This produces situations such as when a 0 constant is returned from a function that the zero register is attempted to be placed into the first return register. These two physical register constraints naturally conflict and nothing is around to generate a move instruction. This happens within
OperandCollectormeaning it's not easy to generate more instructions at that time.The "fix", which is incomplete, that this PR implements is to introduce a pseudo-instruction which has a fixed register definition of the physical register zero. This instruction emits no code and is intended to provide a location for regalloc2 to split bundles by automatically inserting a move in the above situation. To get this working however it required removing an assertion in the
OperandCollectorand ends up violating an invariant of regalloc2 where a virtual register is assigned to a non-allocatable register. This ends up generating instructions which move general purpose registers into the zero register on riscv64, which is unlikely to be what regalloc intended.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
alexcrichton closed without merge PR #7162.
Last updated: Jan 10 2026 at 20:04 UTC