timotimo time to use an allocator that fills new allocations with random data 00:01
maybe?
or, you know, just use valgrind and maybe make sure the allocator it uses cooperates by marking memory regions as "allocated but uninitialized" and such 00:02
brrt uhuh. but this is the register allocator though :-)
timotimo could be a good idea to add support to the spesh allocator for --valgrind and redzones and such, though i wouldn't expect it to find something
right, i'd be filling the register allocator's data with random bytes 00:03
though maybe using rr and just going backwards a bit with a watchpoint is easier
brrt hmm 00:04
in this case, the 0-is-rax-is-illegal rule also works though :-)
timotimo hm, right, it'd always cause trouble, right? 00:07
brrt yeah, and i can detect it easily enough 00:10
brrt ok, going to sleep now, will debug further in the morning 00:27
timotimo the quality of my thoughts has declined sharply during the moving process 00:27
good nigth brrt++ :)
brrt good night timotimo
jnthn 'night brrt 00:35
jnthn also figures it's time for sleep
Geth MoarVM: samcv++ created pull request #798:
RFC Allow optional strict decoding of windows-1251/1252 (new ops)		 01:43
brrt good * #moarvm 09:09
nine /win 9 10:01
buggable nine, Thank you for entering Accidental /win Lottery! The next draw will happen in 3 weeks, 13 hours, 58 minutes, and 50 seconds
jnthn morning o/ 10:21
brrt morning 10:24
nwc10 not totally good *, #moarvm, as currently NQP fails with a SEGV during build 11:12
src/spesh/log.c:152:41: runtime error: member access within null pointer of type 'struct MVMSpeshLog' 11:13
brrt that's not totally good, no 11:36
samcv /win dows 15:26
nwc10 odd 15:31
/win 0
buggable nwc10, Thank you for entering Accidental /win Lottery! The next draw will happen in 3 weeks, 8 hours, 28 minutes, and 25 seconds
nwc10 /win 1
buggable nwc10, Thank you for entering Accidental /win Lottery! The next draw will happen in 3 weeks, 8 hours, 28 minutes, and 24 seconds
nwc10 /win 00
buggable nwc10, Thank you for entering Accidental /win Lottery! The next draw will happen in 3 weeks, 8 hours, 28 minutes, and 20 seconds
nwc10 /win -1
brrt once you start seeing graphs, you start seeing them everywhere... 16:43
case in point
i just realized i can make the linear scan allocator make a graphviz of life range relations
TimToady /win ꧓ 18:06
buggable TimToady, Thank you for entering Accidental /win Lottery! The next draw will happen in 3 weeks, 5 hours, 53 minutes, and 55 seconds
TimToady /win ⅷ 18:18
brrt good evening #moarvm 22:06
MasterDuke brrt: did you see my latest comment on github.com/MoarVM/MoarVM/pull/787/ ? 22:21
brrt didn't
oh, i did, and i thought i responded, but that didn't come through 22:26
MasterDuke i think i'm not quite sure what the overall status of JITting sp_findmeth is. i.e., i know you've been doing some work, but i'm not sure if what you're doing would potentially replace my PR
or would be an optimization to it
afk for a bit, but will check back 22:27
brrt no, your PR is correct :-)
and yes, that was the correct place for the check 22:28
MasterDuke (not quite afk yet apparently). so the first branch is all that's needed, since the entire thing is marked as invokish? or the other way around? 22:30
brrt both branches are needed. but there's a check in there setting a dynamic label 22:31
and branching out to the interpreter
but it's arguably kind of difficult to see if you don't know what you're looking for :-)
what i can do, is lift the internal invokish check out of there in a separate commit and then merge your template 22:32
MasterDuke ahhh
brrt but i'm once more on a quest to debug a linear scan problem 22:33
so that's currenlty occupying my attention 22:34
MasterDuke no worries, just wanted to make sure there wasn't anything i needed to do
brrt :-) 23:03
i found my bug
[Coke] \o/ 23:06
brrt in the final 'cleanup' phase of the linear scan allocator, i'm not taking into account the fact that new live ranges might be added during processing 23:11
of tiles, e.g. during spills 23:12
so the change is to switch from an iterate-the-heap + cleanup model, to iterate-the-list and peek-the-heap model
MasterDuke cool. easy fix? 23:15
brrt hmm, needs a bit of care to ensure that everything keeps on happening in the right order :-)
MasterDuke is this what was blocking merging your optimization branch?
brrt no, blockign merging that is a case of 'not done yet' :-) 23:31
there's a bunch of things i want to experiment with before i merge that 23:32
MasterDuke ahh 23:36
brrt hmm. not so simple to fix after all 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!