How big is the lifetime holes thing in practice? On loops the contiguous-interval model spills way more than it should. Wondering if that alone explains most of the YJIT gap.
Glad to read news on Ruby ZJIT development. I wonder if ZJIT is being used in production at Shopify yet?
I have no idea; but I presume they don't, given that ZJIT today is still much slower than YJIT? [1]
I’ve always wondered about linear scan vs SSA based spilling & regalloc, like libfirm & qbe use:
‘Register spilling and live-range splitting for SSA-form programs’ and ‘Preference-Guided Register Assignment’
It’s much cleaner to code, since you don’t need to generate live ranges explicitly, and can break it up in two passes. Linear scan creates new inactive /active intervals, while the ssa form allocators just reuse the ssa graph. I’ve never benchmarked them back to back though.
How big is the lifetime holes thing in practice? On loops the contiguous-interval model spills way more than it should. Wondering if that alone explains most of the YJIT gap.
Glad to read news on Ruby ZJIT development. I wonder if ZJIT is being used in production at Shopify yet?
I have no idea; but I presume they don't, given that ZJIT today is still much slower than YJIT? [1]
[1]: https://rubybench.github.io
I’ve always wondered about linear scan vs SSA based spilling & regalloc, like libfirm & qbe use:
‘Register spilling and live-range splitting for SSA-form programs’ and ‘Preference-Guided Register Assignment’
It’s much cleaner to code, since you don’t need to generate live ranges explicitly, and can break it up in two passes. Linear scan creates new inactive /active intervals, while the ssa form allocators just reuse the ssa graph. I’ve never benchmarked them back to back though.