brrt \o 06:25
i am in fact no longer fully convinced that a second 'register assignment' loop in linear scan maear scan makes any sense at all 06:30
because you need to be able to find the ' current' live range that stands for a particular value, and that 'current' version lives usuaully in the active set to begin with 06:32
brrt you *can* move it t o a later phase but it is kind of pointlyess 06:39
pointless
brrt hmmm, okay, so let me think about that some more 07:04
while running linear scan, I may have to update existing references to live ranges to other references because the live range themselves have been spilled 07:05
if i wait with register assignment until after the first loop, I can simply read the registers per tile from the updates references 07:06
however, since i already must do the update, updating the register number rather than the reference seems to me to be equivalent
so what i need... is a register assignment primitive that updates the users of the live range to the new register 07:09
brrt so, sucky news, but $employer has just suspended the hackathon time... 10:19
timotimo :o 10:33
brrt yes 11:00
the good news bit is that I think I have a definitive answer to the second-loop problem; it is not necessary and it doesn't simplify anything 11:01
timotimo first-loop problems, man
brrt :-D 11:02
note for future references: I'm going to store the index node-that-references the live range along in the use array of the live ranges, so that I have a complete mapping from live ranges to tile nodes, so that when I assign the actual register to the live range, I can find the tiles that have to be assigned the register to by simply looping over the 'uses' array 11:07
which means that i no longer have to maintain a tile -> live range mapping because the mapping will be in the reverse order, which is the interesting order anyway 11:08
and... if i do that for definitions as well as uses, this generalizes nicely because definitions are always in the '0' index, and I can still always 'reuse' the definitions/uses when splitting/spilling 11:11
but first, lunch &
timotimo ah, nice
timotimo should i continue putting "but got REPR debug_name" stuff into places like the interpreter? 15:57
maybe smaller code would be better
so maybe there should be a function that gets called to build the error message from a few parts
i'm not convinced that's actually smaller
OTOH, we jit a bunch of things, so the size of the interpreter itself isn't as noticable for hot things 16:01
brrt i don't really know the answer to that, tbh 16:34

Powered by Cro and the Raku® Programming Language.

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

Thank you!