dalek arVM/even-moar-jit: 40add84 | brrt++ | src/jit/ (4 files):
Take register allocation out of code generation

Trying to do online (i.e. without lookahead) register allocation was a poor idea (complex, ineffiicent, incorrect results). So it is moved to a separate step, and will be developed more further.
As a result, allocating 'scratch' registers in tiles must be removed as well.		 20:00
MoarVM/even-moar-jit: c9bf2fc | brrt++ | src/jit/ (2 files):
MoarVM/even-moar-jit: Remove register locking logic
MoarVM/even-moar-jit:
MoarVM/even-moar-jit: Because we can't allocate scratch registers anyway, this is no
brrt so, that is at least a bit of progress; my hypothesis is that by slowly moving bits into their right places, i can start working on a real, more complex and correct, allocator 20:07
i.e. kill all the dumb decisions and simplify things first, then build it out 20:11
timotimo neat 20:34
jnthn brrt++ 20:54
TimToady we prefer convergence on a correct solution even it gives the appearance of divergence occasionally :) 21:02
timotimo i just finished the paper on mementos, btw 21:24
timotimo it doesn't give implementation advice, though. like for how the memento map should look, or the allocation site data structure, really 21:28
they also have static frames be movable by the GC, which forced v8 to get a "zombie" state in which static frames survive an additional collection to keep heap integrity
jnthn Yes, most papers leave the reader with some amount of figuring out to do in terms of the details :-) 21:45
timotimo aye 21:54

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!