alexcrichton opened PR #7162 from alexcrichton:rv64-use-zero-reg
to bytecodealliance:main
:
This commit is an attempt to use the
zero
register more often in the riscv64 backend. Currently materializing aniconst 0
value moves thezero
register 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 duringOperandCollector
collection 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_use
rather 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
OperandCollector
meaning 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
OperandCollector
and 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: Oct 23 2024 at 20:03 UTC