4 ms·
Brings me back to the compiler building lab I partook in university. Though before implementing an actual register allocator, we just emitted the same register
by anyfoo 5y ago
Brings me back to the compiler building lab I partook in university. Though before implementing an actual register allocator, we just emitted the same register operands for all instructions, mostly (e)ax, and spilled a lot, really a lot, on the stack. Stupid slow, but hey, seeing our compiler produce runnable code was a good motivator for the next steps!
But we were doing this for 32bit x86, so a lot of the limitations addressed here were not relevant anymore, and our register allocator code was likely far simpler, and probably still less efficient. (It's been at least 10 years now, not sure anymore.)
On a side note, I was surprised when some short time later I looked into Chrome V8's source code, and discovered that it didn't really have a register allocator either. I believe that was quickly addressed (by a new engine actually, if I recall right).
- whizzter 5y agoYep, register allocators are really low priority early on if you're making a JIT(or AOT) compiler for a dynamic language such as JS or Python since there are much larger gains made by just avoiding the interpreter and high level optimizations avoiding type tests since they introduce branches, skipping reference counting, etc. Once all that is done a register allocator starts becoming relevant, and even then you probably want another kind of allocator than is mainstream for lowlevel languages since you might not be doing a full-method compilation or a compilation that shouldn't require a full de-optimization if an divergent type is detected.