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