|
00:05
harrow joined
01:49
ilbot3 joined
|
|||
| MasterDuke_ | . | 01:58 | |
| MasterDuke | . | 01:59 | |
| 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:00 | |
| 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
02:43
colomon joined
03:03
KDr2_c joined
03:06
colomon joined
05:49
domidumont joined
05:55
domidumont joined
05:58
brrt joined,
domidumont1 joined
|
|||
| 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? | ||
| 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. | ||
| brrt | not sure why that happens | ||
| 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:03 | ||
| which has a nice and simple cause and resolution | 06:14 | ||
| it was: bitmap & ((~(1 << shift_out)) | (1 << shift_in)), now it is: (bitmap & (~(1<<shift_out))) | (1 << shift_in) | 06:15 | ||
| 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 | ||
| plus, it's bit was already set by the NEG of (1<< shift_out), so it would never have any effect | |||
| brrt wonders if he can generalize the bitmap handling and whether it makes sense | 06:19 | ||
| Geth | MoarVM/even-moar-jit: 571ef607ab | (Bart Wiegmans)++ | src/jit/linear_scan.c Fix order of shift-in for CALL arg bitmap The OR of the shifted-in value would be applied to the negated bitmask of the shift-out value which would be AND-ed with the original bitmap. The effect is that the shift-out bit would be unset, but the shift-in bit would not be. This would cause that same register to be reused as the 'spare' register for the chain-breaking cycle, while it was really already in use. |
06:23 | |
| MoarVM/even-moar-jit: 01399fb4fb | (Bart Wiegmans)++ | 2 files Add elems REPR op call This is an unoptimized generic routine and is a prime candidate for a specialized JIT (e.g. for VMArray etc.). |
|||
|
07:08
domidumont joined
07:17
brrt joined
07:46
zakharyas joined
|
|||
| brrt | new bug to fix! | 07:47 | |
| jnthn | "new bug to fix" seems to be one of those things as certain as death and taxes... | 08:41 | |
| brrt | true words | 08:48 | |
| hmm, let's try valgrind though | 08:49 | ||
|
08:50
brrt joined
10:06
lizmat joined
|
|||
| timotimo | oh i love texas! | 10:35 | |
| brrt | obviously, my obj_body macro might be wrong... | 12:01 | |
| timotimo | "obviously", "might"? | 12:36 | |
| brrt | hehe | 12:38 | |
| it might be a possibility, but doesn't really seem to be the case | |||
| 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 | |
| surely easier to read than (~(1<<shift_out)) :) | |||
| well, with bitmap & in front | |||
| brrt | matter of fact, i have a set of bitmap-editting routines, but they're supposed to work on pointers | 12:55 | |
| i was just pondering about doing just that | |||
| timotimo | you can make your functions always take pointers and then just take a reference where you're invoking, right? | 12:56 | |
| brrt | uhuh | ||
| but | |||
| i need to make all bitmaps at least 64 bits wide though | |||
| timotimo | oh, hm | 12:57 | |
| 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? | ||
| brrt | not anymore | 13:07 | |
| i've changed a tile to be much shorter | |||
| that changes register usage and re-breaks elems | 13:08 | ||
| i'm not sure why | |||
| timotimo | uh oh :) | 13:12 | |
| brrt | huh, i will figure out, worry not | 13:59 | |
| 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:04 | |
| brrt | haven't worked that out in full detail just yet | 14:09 | |
| howeve | |||
| my intention is that such files would go alongside the repr files | |||
| C files | |||
| so you'd have MVMArray.c, MVMArray.h, and MVMArray.expr | |||
| 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:10 | ||
| timotimo | right | 14:12 | |
| gist.github.com/timo/2b25fca488f17...5863343d78 - which ops appear most often in expr jit pieces | 14:13 | ||
| brrt | 21096 set :-o | 14:17 | |
| long tails indeed | 14:18 | ||
| timotimo | we have a crapton of set instructions, yeah | ||
| 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 | |||
| brrt | NULL instructions are fortunately well suited for common subexpression elimination | 14:20 | |
| timotimo | right | ||
| they grab the same VMNull pointer and stick them into a whole bunch of registers | |||
| at some point we might be able to set the values with a vectorized instruction :P | |||
| jnthn | In theory most of those are thrown out because the value is unused | 14:36 | |
| (and the SSA "proves" it) | 14:37 | ||
|
15:06
brrt joined
15:21
AlexDani` joined,
domidumont joined
|
|||
| brrt | okay… all of the sudden i've got an object with negative elems (or very, very large, depending on your pov) | 15:31 | |
| ugh, i can't see what is going wrong, at all :-( | 15:44 | ||
| timotimo | maybe find a different op that'll explode in the same way and compare & contrast? | 15:45 | |
| brrt | hmmm | 15:47 | |
| 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? | ||
| brrt | hmmm | 15:57 | |
| jnthn | Could also be one of the spesh lookup ops doing a wrong offset... | 16:06 | |
| (The ones that dig straight into an object body) | |||
|
16:07
domidumont1 joined
16:42
lizmat joined
17:00
domidumont joined
17:45
robertle joined
17:57
Ven joined
18:16
Ven_ joined
18:32
Ven_ joined
18:58
Ven joined
19:04
AlexDaniel joined
19:05
Ven_ joined
19:19
lizmat joined
19:43
Ven_ joined
20:31
Ven joined
20:38
Ven_ joined
20:45
Ven_ joined
20:51
Ven_ joined
22:04
lizmat joined
22:57
nebuchadnezzar joined
|
|||