primoly (Dec 06 2024 at 20:08): primoly (Dec 06 2024 at 20:08):Hello. Could regalloc3 solve this issue with rematerialisation? I have this branch using regalloc3 as the backend for regalloc2 (just a more up to date variant of this) and then use it in Wasmtime/Cranelift. But since regalloc2 does not support rematerialisation, the regalloc3.rs implementation for can_rematerialize always returns None. If Cranelift where to use regalloc3 directly and implemented can_rematerialize properly, would that solve, for instance, the issue of unneeded spills here?
Amanieu (Dec 06 2024 at 20:34):Yes, regalloc3 will never spill a rematerializable value. However it would still requires that Cranelift provide this information to the register allocator.
Chris Fallin (Dec 06 2024 at 20:55):For anyone interested in this -- the path toward experimenting directly with RA3 by porting Cranelift onto its APIs would be:
regalloc2-provided registers and operands onto RA3 equivalents.-O0). Probably we would want/need to lift that restriction in RA3 instead.My PR to move to RA2 (https://github.com/bytecodealliance/wasmtime/pull/3989) is an upper bound for effort: it shows what it takes to lift the whole compiler onto a new set of types, but also involved refactors for RA2's SSA-based VCode. Nevertheless expect the diff to be nontrivial.
If all that work is done, then there would be some process questions around maintenance and vetting and code-review -- RA2 was fully code-reviewed and vetted per BA standards, and we would need to do the same for RA3 -- and we'd want more of the Cranelift team to be familiar with RA3 as well since the regalloc is a critical piece of the backend. But all those things would come after a "direct port" prototype showing benefits.
Last updated: Dec 23 2024 at 12:05 UTC