01:56 tokuhirom joined 03:51 tokuhirom joined 05:24 tokuhirom joined 05:53 dalek joined 07:02 domidumont joined 07:06 domidumont joined 09:01 cognominal joined 09:25 tokuhirom joined 09:55 cognominal joined 10:54 pyrimidine joined 12:30 Ven joined 12:45 domidumont joined 14:17 Ven joined 15:24 tokuhirom joined 15:55 _longines joined 17:05 domidumont joined 18:06 TimToady joined 19:25 tokuhirom joined
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
20:00 brrt joined
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
21:27 tokuhirom joined
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
21:30 TimToady joined
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
23:23 tokuhirom joined