01:14 japhb joined 02:03 pyrimidi_ joined 02:25 pyrimidine joined 02:48 ilbot3 joined 03:15 pyrimidi_ joined 04:31 pyrimidine joined 06:13 sivoais joined 06:39 pyrimidi_ joined 08:02 pyrimidine joined 08:34 domidumont joined 08:39 domidumont joined 09:14 domidumont joined
dalek arVM/even-moar-jit: df718f4 | brrt++ | / (6 files):
Implement register naming macro

This enables syntax like MVM_JIT_REG(RSP) to expand to MVM_JIT_ARCH_X64_RSP, which is used in the MVM_JIT_REGISTER_REQUIRE macro.		 09:56
10:29 brrt joined
brrt good * #moarvm 10:30
lizmat brrt o/
brrt \o lizmat
dalek arVM/even-moar-jit: 9ccafc7 | brrt++ | / (8 files):
Allow for 'definition' tiles

Definition tiles don't need an emit function but can operate as placeholders in the tiling process and as declarations of specific registers.		 10:41
brrt .... the additive effect of incremental change never ceases to amaze me 10:47
timotimo "how did this accumulate so much cruft? ... oh." 10:48
on the way to my parents, i drove by a city called Kruft 10:49
dalek arVM/even-moar-jit: e9d55ff | brrt++ | src/jit/x64/tile (3 files):
Make more definitions out of tiles

These 'tiles' had void implementations, anyway.		 10:52
timotimo documentation void if tile removed 10:53
sorry. implementation void if tile removed*
brrt it can also be used to uncruft ;-)
vendethiel
.oO( why did you name that file tiles.list and not tiles.lisp ) :P
 11:00
timotimo hey ven 11:01
the moment lisp-like stuff gets mentioned, you appear! ;)
brrt if i named it tiles.lisp, people would assume it could do cons, car, cdr, and lambda 11:07
and it can't do any of those :-P
timotimo hehe
fair enough
brrt (wouldn't be difficult to write, by the way.....) 11:08
timotimo we could implement car and cdr to get the first and second half of a machine word :P
brrt well, 32 bit pointers, 64 bit words...
we're kidding, right, but in seriousness 11:13
i think LISP is probably simpler to write in assembly than it is in C
timotimo :D 11:14
dalek arVM/even-moar-jit: a374a93 | brrt++ | / (4 files):
Parse register annotations on tiles

Required some additional flexibility in tile keyword syntax. Also rename the array of tile templates from tile_rules to tile_templates.		 11:25
arVM/even-moar-jit: 694ff78 | brrt++ | docs/jit/plan.org:
Update plan.org
 11:33
brrt it needs a tiny bit of thought to use the register requirements 11:34
the good bit is:
timotimo beh, the org renderer github uses doesn't show the difference between DONE and TODO
brrt i can now (define (tc) reg:r14) and it will be correctly parsed as a 'void' tile (no emit function) that defines register r14
oh, that sucks 11:35
org is such a nice format and such a nice tool
timotimo i hear fantastic things about it all the time
one of my profs at uni used org to make all of his website
though i believe slides and such were all latex beamer 11:36
brrt which is something you can make org export to ;-)
org exports to latex, to opendocument, to 'text', to a bunch of other things
timotimo fair enough :) 11:37
brrt i started using it after my thesis supervisor was using it. it was the only thing he was using emacs for, i was using emacs for anything but that, something had to change
the next commit will hopefully remove the special-case logic in register.c to deal with TC/CU/STACK/LOCAL 11:38
timotimo :D
brrt seriously, i can't recommend it enough 11:41
timotimo i wanted to use a vim-org-thing at some point. didn't end up going through with it at all
brrt oh well :-) not sure if that would make 100% sense since org is also partially awesome because of the whole emacs ecosystem 11:43
timotimo nah, it's because i hate getting organized 11:45
brrt i'm not organized. it's my projects that become slightly less disorganized
more to the point, it's an excellent way to keep track of project state if you have to interrupt them many times 11:46
timotimo mhm
i know all about interrupting projects many times!
brrt indeed 11:50
as do i
for instance, in the GridKit project i'm developing, I know that there's stuff I need to investigate regarding to line lengths. I don't know exactly what, but the org file i maintain does, so that next time i have some time for it, I'll know what to do 11:51
timotimo i should do something similar for all my little perl6-related projects 11:53
brrt come over... to the GNU side (muhahaha) 11:55
12:02 pyrimidine joined
lizmat .tell jnthn as a datapoint: t/spec/S11-modules/nested.t very occasionally flaps (no tests seen) for me (like less then 1/20) 12:10
yoleaux2 lizmat: I'll pass your message to jnthn.
13:16 brrt joined
brrt i've killed rakudo settings build again 13:18
timotimo oh, oops 13:22
lizmat well, that's a starting point :-) 13:23
brrt :-) 13:29
i'll figure out why soon enough
jit-bisect again
so for my next magic trick, i'm thinking of reducing the size of MVMJitExprNode to 32 bits, and write a macro to 'split' 64 bit values into two parts 13:34
timotimo what, car and cdr? :) 13:35
brrt now i'm going to call that macro CARCDR. thanks 13:46
lizmat timotimo: re sort and having the || nqp::cmp_i($a,$b) in each comparator: does Perl6 guarantee the order of elements considered to be the same ? 13:49
timotimo you mean whether or not sort is stable? 13:54
lizmat I guess
timotimo i'm not sure we guarantee that
could randomize considered-same-elements and see if spec tests break
lizmat I mean: *if* we guarantee that, then maybe we should do that in p6store internally 13:55
if we don't, then we can simplify the default sort
will spectest
timotimo there's a known set of sort algorithms that are stable vs ones that are not; it could be warranted to offer a stable-sort or sort :stable to our users for special cases 13:56
and if the user doesn't specify it, we're free to choose whatever
i hear many will start with quicksort and if the run time seems bad, it'll turn into merge/heap sort on the fly 13:57
lizmat timotimo: non-stable sort has quite a few spectest errors 14:14
timotimo: do you happen to know if p6sort is used in other places than src/core/*.pm ? 14:16
timotimo i don't think it was
hell, i even (had to?) re-implement sorting for the profiler output 14:17
lizmat afk& 14:32
15:15 brrt joined
brrt i might want to robustify the bisecter a bit 15:24
15:26 dogbert17 joined
nwc10 .tell jnthn new ASAN barfage from spectest6: paste.scsys.co.uk/540350 16:07
yoleaux2 nwc10: I'll pass your message to jnthn.
timotimo uh oh 16:08
nwc10 yes, but "new" is probably "new to me"
likely it's not a new cause
timotimo oh, i didn't put compunit_string_mem_share back in
nwc10 I rarely run the Perl 6 harness
timotimo so we have a realloc that's invalidating some internal pointers? 16:09
nwc10 I really don't know.
I can play teddy bear
but I can't actually say anythign useful
other than "this might be a really old bug, and it might hit only really rarely"
timotimo hehe 16:10
that's kinda strange 16:16
16:16 zakharyas joined
timotimo all i can imagine is you hit the exact moment where realloc was happening 16:17
like, one thread was accessing cu->strings, then it was getting strings[idx]
and in between that, realloc wrote a new address to cu->strings
i know how we can fix this 16:18
we can use the "free at safepoint" mechanism for this
16:25 vendethiel- joined
timotimo huh, we realloc to add one single slot every time we add a string ... but it's only needed for inlining across CUs anyway ... 16:31
maybe we want a "fixed_size_increase_needs_copy" or something 17:13
so we don't have to memcpy all the darn time
17:54 FROGGS joined 17:58 Ven joined
dalek arVM/even-moar-jit: 9fc2eeb | brrt++ | src/jit/register.c:
Should clear the values array after use

This should never break anything, but did anyway, during CORE.setting compilation. Possibly because undefined value reading optimization nonsense. And this fixes it.		 19:08
lizmat timotimo: do you have any emotional attachment to the p6sort code ? 20:26
timotimo i do not 20:28
lizmat ok, then I will do some surgery which *may* cause the complete removal of p6sort 20:29
timotimo that's fair 20:31
lizmat hmmm... if the proto "is nodal", do we need to repeat that on the multi candidates ? 20:47
timotimo hm, i don't think so. but it's a good question 20:48
21:41 domidumont joined 22:45 pyrimidine joined 23:01 geekosaur joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!