[Coke] samcv: sorry, not yet a moarvm hacker. 00:48
[Coke] waves from the highway.
brrt ohai #moarvm 20:02
nwc10 good UGT, brrt
brrt i've figured out why i keep having memory corruption in the linear scan allocator 20:03
interestingly it's because i should be using a linked list instead of an array 20:04
also, happy new prime year nwc10
or well...using a linked list is one way to solve it... and probably the simplest 20:06
lizmat brrt nwc10 good 2017 wished to you too
brrt although i liked my array-based approach better on aesthetic grounds 20:07
you too lizmat!
nwc10 you three, or, to be on the safe side, you *
brrt2 i'm 20:10
suspicious that the train wifi is blocking the google play store 20:11
lizmat nwc10: we will 20:12
dalek arVM/even-moar-jit: 5fbea8d | brrt++ | src/jit/linear_scan.c:
Actually release registers after use

Forgetting this meant that allocating larger sequences didn't really work.
This implementation will fail due to memory corruption, because the second loop of determine_live_ranges will create more definitions than computed in the first loop, because it doesn't account properly for aliasing operations.		 21:04
brrt okay, so to elaborate a bit on the cryptic comment in that 21:09
i compute live ranges in two easy steps
one, i compute the sets of things that become a single live range, taking into account aliases and PHI nodes 21:10
brrt two, i fill in the live ranges by creating references from the live range (describing the value) to the tiles (using the value) in a buffer 21:10
now my problem is that i'm causing buffer overruns because as it happens the second loop (creating the live ranges) does not take into account aliases and phi nodes as the first loop 21:12
(all references go and live in a single buffer. this is efficient and nice and what i meant with 'aesthetic preference')
now, i can do either of the following things: 21:13
i replicate the first loop over the tiles into the second loop
but, that feels really, really icky 21:14
as if there's no work being done in the first loop at all (not true, but feels that way)
the second option is to use a data structure that supports the operation that i really need - which is append the definitions and uses as i find them, and that data structure is clearly a linked list 21:15
in which case, i can fold the second and first loop into one. elegance win!
i still need to have a new second loop to 'harvest' the created live range into the worklist that needs to be allocated for 21:16
lizmat folding loops is generally a good idea :-)
brrt but that's a much simpler loop altogether
i agree :-)
(there are two roughly equivalent ways to do the harvesting, with equivalent complexity) 21:22
lizmat ack 21:24
lizmat is tired and goes to bed
brrt too 21:25
will try to implement tomorrow :-) 21:26

Powered by Cro and the Raku® Programming Language.

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

Thank you!