Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-05-18

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:05 harrow joined #moarvm
01:49 ilbot3 joined #moarvm
01:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:58 MasterDuke_ .
01:59 MasterDuke .
02:00 yoleaux 17 May 2017 07:42Z <brrt> MasterDuke: in this case lt, gt, eq etc are the expr ops, cmp is the tile that can compile all of them (because its the same machine-code instruction
02:01 MasterDuke .ask brrt so if i just created some new templates in src/jit/core.expr they'll get picked up and used automatically?
02:01 yoleaux MasterDuke: I'll pass your message to brrt.
02:37 njmurphy joined #moarvm
02:43 colomon joined #moarvm
03:03 KDr2_c joined #moarvm
03:06 colomon joined #moarvm
05:49 domidumont joined #moarvm
05:55 domidumont joined #moarvm
05:58 brrt joined #moarvm
05:58 domidumont1 joined #moarvm
06:00 brrt i've found the problem, at least for elems
06:00 yoleaux 02:01Z <MasterDuke> brrt: so if i just created some new templates in src/jit/core.expr they'll get picked up and used automatically?
06:01 brrt .tell MasterDuke yes; i think there's a parser bug somewhere in there which means you need to have an extra newline after the last template
06:01 yoleaux brrt: I'll pass your message to MasterDuke.
06:01 brrt not sure why that happens
06:03 brrt the spare register used for the 'musical chairs' topological cycle breaking is the same as the one used to allocate the register used for CALL, rax, which makes sense because it is always guaranteed to be free
06:14 brrt which has a nice and simple cause and resolution
06:15 brrt it was: bitmap & ((~(1 << shift_out)) | (1 << shift_in)), now it is: (bitmap & (~(1<<shift_out))) | (1 << shift_in)
06:16 brrt the difference is that the shift_in isn't OR-ed in correctly in the first, because it is overruled by the AND with the bitmap
06:16 brrt plus, it's bit was already set by the NEG of (1<< shift_out), so it would never have any effect
06:19 * brrt wonders if he can generalize the bitmap handling and whether it makes sense
06:23 Geth ¦ MoarVM/even-moar-jit: 571ef607ab | (Bart Wiegmans)++ | src/jit/linear_scan.c
06:23 Geth ¦ MoarVM/even-moar-jit: Fix order of shift-in for CALL arg bitmap
06:23 Geth ¦ MoarVM/even-moar-jit:
06:23 Geth ¦ MoarVM/even-moar-jit: The OR of the shifted-in value would be applied to the negated bitmask
06:23 Geth ¦ MoarVM/even-moar-jit: of the shift-out value which would be AND-ed with the original
06:23 Geth ¦ MoarVM/even-moar-jit: bitmap. The effect is that the shift-out bit would be unset, but the
06:23 Geth ¦ MoarVM/even-moar-jit: shift-in bit would not be. This would cause that same register to be
06:23 Geth ¦ MoarVM/even-moar-jit: reused as the 'spare' register for the chain-breaking cycle, while it
06:23 Geth ¦ MoarVM/even-moar-jit: was really already in use.
06:23 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/571ef607ab
06:23 Geth ¦ MoarVM/even-moar-jit: 01399fb4fb | (Bart Wiegmans)++ | 2 files
06:23 Geth ¦ MoarVM/even-moar-jit: Add elems REPR op call
06:23 Geth ¦ MoarVM/even-moar-jit:
06:23 Geth ¦ MoarVM/even-moar-jit: This is an unoptimized generic routine and is a prime candidate for
06:23 Geth ¦ MoarVM/even-moar-jit: a specialized JIT (e.g. for VMArray etc.).
06:23 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/01399fb4fb
07:08 domidumont joined #moarvm
07:17 brrt joined #moarvm
07:46 zakharyas joined #moarvm
07:47 brrt new bug to fix!
08:41 jnthn "new bug to fix" seems to be one of those things as certain as death and taxes...
08:48 brrt true words
08:49 brrt hmm, let's try valgrind though
08:50 brrt joined #moarvm
10:06 lizmat joined #moarvm
10:35 timotimo oh i love texas!
12:01 brrt obviously, my obj_body macro might be wrong...
12:36 timotimo "obviously", "might"?
12:38 brrt hehe
12:38 brrt it might be a possibility, but doesn't really seem to be the case
12:41 timotimo brrt: i think it's somewhat common to have a CLEAR_BIT and SET_BIT macro, at least i've seen it a bunch in embedded development
12:41 timotimo surely easier to read than (~(1<<shift_out)) :)
12:41 timotimo well, with bitmap & in front
12:55 brrt matter of fact, i have a set of bitmap-editting routines, but they're supposed to work on pointers
12:55 brrt i was just pondering about doing just that
12:56 timotimo you can make your functions always take pointers and then just take a reference where you're invoking, right?
12:56 brrt uhuh
12:56 brrt but
12:56 brrt i need to make all bitmaps at least 64 bits wide though
12:57 timotimo oh, hm
13:06 brrt that's hardly a real problem, but then, the breakage has some more priority
13:06 timotimo what are you experiencing this breakage with? elems works fine now, right?
13:07 brrt not anymore
13:07 brrt i've changed a tile to be much shorter
13:08 brrt that changes register usage and re-breaks elems
13:08 brrt i'm not sure why
13:12 timotimo uh oh :)
13:59 brrt huh, i will figure out, worry not
14:04 timotimo so, if we want special implementations for reprs, we will be writing .expr files; how do we properly refer to them from the reprs? and where do the files in question go?
14:09 brrt haven't worked that out in full detail just yet
14:09 brrt howeve
14:09 brrt my intention is that such files would go alongside the repr files
14:09 brrt C files
14:09 brrt so you'd have MVMArray.c, MVMArray.h, and MVMArray.expr
14:10 brrt and the script would compile that to MVMArray_expr.h, and you'd be called a special function similar to repr->spesh, and it would take the expr tree, and apply the template
14:12 timotimo right
14:13 timotimo https://gist.github.com/timo/2b25fca488f179a29c9a555863343d78 - which ops appear most often in expr jit pieces
14:17 brrt 21096 set :-o
14:18 brrt long tails indeed
14:18 timotimo we have a crapton of set instructions, yeah
14:18 timotimo and most of these null instructions are likely from us clearing a frame with VMNull before the code runs; we have dead-code-elimination throw out unnecessary ones
14:20 brrt NULL instructions are fortunately well suited for common subexpression elimination
14:20 timotimo right
14:20 timotimo they grab the same VMNull pointer and stick them into a whole bunch of registers
14:20 timotimo at some point we might be able to set the values with a vectorized instruction :P
14:36 jnthn In theory most of those are thrown out because the value is unused
14:37 jnthn (and the SSA "proves" it)
15:06 brrt joined #moarvm
15:21 AlexDani` joined #moarvm
15:21 domidumont joined #moarvm
15:31 brrt okay… all of the sudden i've got an object with negative elems (or very, very large, depending on your pov)
15:44 brrt ugh, i can't see what is going wrong, at all :-(
15:45 timotimo maybe find a different op that'll explode in the same way and compare & contrast?
15:47 brrt hmmm
15:54 brrt i'm wondering if i'm mssing a gc sync or something like that
15:54 timotimo have you tried setting all the debug variables up to 11?
15:57 brrt hmmm
16:06 jnthn Could also be one of the spesh lookup ops doing a wrong offset...
16:06 jnthn (The ones that dig straight into an object body)
16:07 domidumont1 joined #moarvm
16:42 lizmat joined #moarvm
17:00 domidumont joined #moarvm
17:45 robertle joined #moarvm
17:57 Ven joined #moarvm
18:16 Ven_ joined #moarvm
18:32 Ven_ joined #moarvm
18:58 Ven joined #moarvm
19:04 AlexDaniel joined #moarvm
19:05 Ven_ joined #moarvm
19:19 lizmat joined #moarvm
19:43 Ven_ joined #moarvm
20:31 Ven joined #moarvm
20:38 Ven_ joined #moarvm
20:45 Ven_ joined #moarvm
20:51 Ven_ joined #moarvm
22:04 lizmat joined #moarvm
22:57 nebuchadnezzar joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary