You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The regalloc2 crate provides a good API (VReg, PReg, Operand, Function, etc) for interacting with a register allocator. It would be nice if other register allocator backends could be made available with the same API to simplify integration on the embedder side.
What I specifically have in mind is a "fast" backend that simply allocates registers in a single pass with the goal of minimizing compilation time. This will have a huge impact on compilation time since my compiler spends 80% of its time in register allocation. In practice I expect to use this for a tiering JIT where hot code can later be re-compiled using the slow regalloc backend that produces better code.
The text was updated successfully, but these errors were encountered:
Agreed -- either a linear-scan (in the classical sense, with precomputed live ranges and evicting furthest-future-used values) or a true single-pass allocator (as baseline compilers typically do, evicting all values to stackslots at merge-points and evicting all or per LRU on running out of registers) would be great to have. I don't have the bandwidth to work on this now but I'd be happy to review it if you or someone else wants to work on this.
The regalloc2 crate provides a good API (
VReg
,PReg
,Operand
,Function
, etc) for interacting with a register allocator. It would be nice if other register allocator backends could be made available with the same API to simplify integration on the embedder side.What I specifically have in mind is a "fast" backend that simply allocates registers in a single pass with the goal of minimizing compilation time. This will have a huge impact on compilation time since my compiler spends 80% of its time in register allocation. In practice I expect to use this for a tiering JIT where hot code can later be re-compiled using the slow regalloc backend that produces better code.
The text was updated successfully, but these errors were encountered: