timotimo | just randomly tossing out there: "cannot get template for "; 7.8k wval, 5.5k prepargs, 4444 sp_findmeth, 4.1k atpos_i, 3.4k. sp_guardconc, 3k elems, 2.8k die, 2.5k unless_o, 2k smrt_strify, 1.9k getdynlex, 1.7k atpos_o | 00:15 | |
there's a bunch of _i ops in there, too. those should be kind of doable around now? | 00:16 | ||
box_1, push_1, getattr_i, lt_i, gt_i, pop_i, ne_i, eqaddr (i count this for reasons), bindpos_i, eq_i | 00:17 | ||
eq_i isn't the last one, but that's already only 400 occurences | |||
all of this for the core setting compilation | |||
i don't quite remember what exact metrics we'd use for "we should leave this for the template jit" | 00:20 | ||
if_* and unless_* are jumpy, and i don't think we do stuff across BBs at all? | 00:29 | ||
i do see Block{...} stuff, but i expect that's blocks at the assembly level, not the moarvm bytecode level (aka spesh level) | 00:31 | ||
MasterDuke_ | timotimo: doable for the new jit or old? | 00:37 | |
yoleaux | 15 May 2017 09:04Z <jnthn> MasterDuke_: It'll probably be tricky to make them work in the general case (think native arrays, for example; I'm not immediately sure how we'd make them work in that case). I suspect getting them correct even on simple variables will be a bit tricky. So, maybe some day, but it won't be entirely easy. | ||
timotimo | MasterDuke_: new jit, the old jit had these for ages | 00:40 | |
MasterDuke_ | good, would have been surprised otherwise | 00:41 | |
timotimo | i uploaded a "coresettingjitlog.txt.xz" onto the whateverable server | 00:42 | |
if you want to take a look yourself | |||
(i don't really understand the output terribly well, either) | |||
MasterDuke_ | and implementing the ops for the new jit means writing those s-expr things brrt has mentioned? | 00:43 | |
timotimo | aye | 00:44 | |
perhaps at some point a tile would have to be written for something | 00:45 | ||
tiles are the things that can turn a piece of s-expr stuff into an actual piece of assembly | 00:46 | ||
that's a major part of the secret sauce | |||
those s-expr pieces can be tiled over with assembly ops in different ways | |||
if we get good cost heuristics for those we can probably get some good assembly code out of the whole thing | 00:47 | ||
MasterDuke_ | but you don't need a new tile for every new bit of s-expr? | ||
timotimo | depends on what you mean by "bit" i guess? | 00:48 | |
MasterDuke_ | so lt_i and gt_i for example? | 00:49 | |
timotimo | oh, no | ||
s-exprs work in terms of something closer to assembly | |||
there's a tile named "cmp" that matches things like (lt reg1 reg2) | 00:51 | ||
i forgot how to spell registers at the moment | |||
i think i'll go to bed now, i'm pretty tired | |||
you can check the contents of src/jit/x64 inside the even_moar_jit branch | |||
the .dasc file is code that spits out assembly, the .list is code that tells what an s-expr-piece can look like for the given piece of assembly to be appropriate | 00:52 | ||
MasterDuke_ | so you write lt and gt in terms of cmp and you don't need a new tile? | ||
later... | 00:53 | ||
timotimo | i think that's how | ||
MasterDuke_ | interesting | 00:54 | |
timotimo | i've actually forgotten how exactly the eq, lt, gt, ne, le, ge actually get the right piece of assembly chosen | ||
okay, bedtime | 00:56 | ||
i've stumbled over this exact thing at least once before and brrt had to explain it to me | |||
sad that the explanation apparently gone to waste :( | |||
MasterDuke_ | yeah, i should go back and read his blog post again... | 00:57 | |
good luck with the bed | |||
timotimo | it's an uphill battle | 00:58 | |
MasterDuke_ | maybe some shims under the legs to level it out? ;) | 01:00 | |
01:49
ilbot3 joined
05:31
brrt joined
05:42
domidumont joined
06:22
domidumont joined
|
|||
Geth | MoarVM/even-moar-jit: 417055e59c | (Bart Wiegmans)++ | 2 files Do not enqueue transfers without inbound registers Enqueuing unexecutable transfers breaks the required transfers mechanism as we would count more transfers as executed than were actually done. |
06:25 | |
MoarVM/even-moar-jit: 983ecd5de7 | (Bart Wiegmans)++ | 2 files Add wval template As a function that returns a value, interesting correctness test |
|||
06:30
domidumont joined
06:34
Ven joined
07:37
brrt joined
|
|||
brrt | timotimo: that is pretty much all correct, yes | 07:38 | |
i'm now trying atpos_o and unsurprisingly, stuff blows up | 07:39 | ||
i'll figure out why yet :-) | |||
.tell MasterDuke: you write it in terms of one of the expr ops (src/jit/expr_ops.h) and those are matched to t iles | 07:41 | ||
yoleaux | brrt: What kind of a name is "MasterDuke:"?! | ||
07:41
AlexDaniel joined
|
|||
brrt | .tell 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 | 07:42 | |
yoleaux | brrt: I'll pass your message to MasterDuke. | ||
07:48
zakharyas joined
07:52
zakharyas joined
08:15
domidumont1 joined
08:32
robertle joined
08:39
nwc10 joined
09:55
robertle joined
|
|||
timotimo | ah, i missed the expr ops, that'd be why i didn't get it | 11:55 | |
12:27
domidumont joined
|
|||
brrt | :-) | 12:42 | |
okay, i'm going to try and figure out why atpos_o and elems explode so hard | 12:43 | ||
timotimo | when we have common subexpression extraction, we'll be able to make virtual repr calls on the same object consecutively cheaper, right? | 13:17 | |
because the repr struct only has to be looked up once? | |||
13:23
brrt joined
|
|||
brrt | in theory, but no | 13:25 | |
in theory *yes | |||
because, if you call a function, you're going to spill your live values anyway | |||
timotimo | ah, hmm. | 13:26 | |
well, hopefully we'll be able to devirtualize a whole lot of calls in spesh anyway | |||
14:26
FROGGS joined
|
|||
brrt | the improved jit bisect works really pretty smoothly, if i do say so myself | 14:36 | |
timotimo | sweet | ||
Zoffix | awesome | ||
timotimo | does that mean you were able to figure out atpos_o and elems? :) | 14:37 | |
brrt | well, haven't had much time for it yet | 14:43 | |
but it does cut down on the search spcae to a large extent | |||
i mean, i now know that elems() is broken by itself, and i know which frame that first manifets | 14:44 | ||
14:45
domidumont joined
|
|||
timotimo | cool | 15:02 | |
15:20
brrt joined
15:42
brrt joined
15:58
zakharyas joined
16:12
TimToady joined
16:38
AlexDaniel joined
17:41
robertle joined
18:49
domidumont joined
20:50
AlexDaniel joined
21:06
chatter29 joined
22:25
AlexDaniel joined
23:06
Voldenet joined
|