|
00:42
nwc10 joined
00:53
kjs_ joined
02:34
FROGGS joined
02:48
ilbot3 joined
05:56
vendethiel joined
06:42
vendethiel joined
06:52
domidumont joined
06:53
domidumont joined
06:59
domidumont joined
08:58
lizmat joined
09:18
lizmat joined
09:23
vendethiel joined
09:38
lizmat joined,
mojca joined
|
|||
| mojca | is the following compile warning expected? src/jit/emit_x64.dasc:274:86: warning: shift count >= width of type [-Wshift-count-overflow] | 09:38 | |
| it's about shifting for 32 "dasm_put(Dst, 94, (unsigned int)((uintptr_t)obj), (unsigned int)(((uintptr_t)obj)>>32), Dt1E([reg]));" | |||
|
09:58
kjs_ joined
|
|||
| nine | mojca: what platform are you on? | 10:40 | |
| mojca | OS X | ||
| nine: x86_64 to be complete | 10:41 | ||
| oh, wait, maybe I just forgot about recent changes | |||
| but I'm not building for i386, at least not intentionally | |||
| oh, wait … stupid me | 10:42 | ||
| the warnings come from an unintentional universal build (I did just "port upgrade moarvm", forgetting that I had installed this as universal earlier) | |||
| I'm sorry for the noise; I'll try again, but I think that's it | 10:43 | ||
|
10:48
kjs_ joined
|
|||
| mojca | nine: indeed, sorry for the false alarm; I tried building just for x86_64 again and the warnings are gone; it was just confusing and I forgot the issue from one or two months back | 10:53 | |
| nine | mojca: then the warning fulfilled it's purpose :) | 10:54 | |
| mojca | in a sense; I would be happier if that code was simply commented out, but it's fine as it is | 10:55 | |
| tha code would not be used on i386 anyway | |||
| nine | Is there any i386 support at all in the jit? | 10:57 | |
| mojca | nine: no, it's not, but it has recently been circumvented at runtime | 11:11 | |
| earlier it just crashed | |||
|
11:12
kjs_ joined
11:47
lizmat joined
14:33
TimToady joined
15:07
Ven joined
15:21
brrt joined
15:34
zakharyas joined
|
|||
| timotimo | Constructing JIT graph (cuuid: cuid_2975_1457271489.25971, name: 'infix:<*>') | 15:34 | |
| BAIL: op <param_rp_n> | |||
| ^- required positional, num ... shouldn't we be able to jit this already? | |||
| brrt: ^? | 15:35 | ||
| brrt | oh, yes | ||
| pending refactoring these ops | 15:36 | ||
| timotimo | oh | ||
| brrt | :-P | ||
| timotimo | ah well | ||
| brrt | to recall what went wrong there | ||
| these functions return a struct | |||
| with a value and a boolean-if-they-received-that-value | |||
| they should, probably, be refactored to return success/failure and write the value to a pointer arg | 15:37 | ||
| timotimo | oh, atposref_n aborts jitting of this AT-POS | ||
| i can implements this | |||
| brrt | cool | ||
| brrt is implementing a jit test bisector | |||
| timotimo | neat | 15:38 | |
| based on the "fuel" metaphor, i see | |||
| brrt | fuel metaphor? | 15:43 | |
| timotimo | yeah | 15:45 | |
| the optimizer (or jit in this case) would "run on" fuel and only do stuff until it "runs out" | |||
| so if you want to find some place that breaks things, you give it more or less fuel and see where it runs out | 15:46 | ||
| brrt | hahahah | 15:47 | |
| cool | |||
| timotimo | -Constructing JIT graph (cuuid: cuid_4876_1457271489.25971, name: 'AT-POS') | ||
| -BAIL: op <atposref_n> | |||
| \o/ | |||
| my local changes are teaching facts.c about all the *ref_* ops creating the corresponding types from the HLL and jitting the atposref_* ops | 15:48 | ||
| brrt | \o/ | ||
| timotimo | i should have a closer look if the *ref_* ops are currently appearing in the after-inlining-all-the-things output in my current test code | ||
| if they do, i could start working on spesh going directly via the original object and whatever register has the index/name/... | 15:49 | ||
| in any case, this code generates a gigantic amount of reference objects | |||
| to the point where 10% run time is spent in GC | |||
| we're taking lexical refs to pass to postcircumfix:<[ ]> ;_; | 16:06 | ||
| as indices ;_; | |||
| maybe because we specify \key ? | 16:09 | ||
| but we also have candidates with the int position available | 16:10 | ||
| dalek | arVM: 6b2e4e0 | timotimo++ | src/jit/graph.c: jit the atposref_* ops |
16:31 | |
| arVM: a3a5d0f | timotimo++ | src/spesh/facts.c: all the ref ops now properly set up facts in spesh |
|||
| timotimo pushes before heading out | 16:32 | ||
| dalek | arVM/even-moar-jit: 207a337 | brrt++ | src/ (3 files): Add maximum jit expr compile indexes This is to allow 'easy' bisection of the relevant broken piece of code. To be coupled with a bisection script. |
16:34 | |
| arVM/even-moar-jit: cd79c8e | brrt++ | tools/jit-bisect.pl: Add tool for expr JIT bisecting |
|||
| brrt | we can now bisect where a particular piece of code really breaks | 16:35 | |
| if it is a piece of the expression jit, at least | |||
| nine | This segfault worries me a bit: gist.github.com/niner/dfdb4ef9ce9ac040abc2 | ||
| brrt | hmm | 16:36 | |
| rerun with --optimize=0 --debug | |||
| nine | Note that this is in Inline::Perl6 which is hacky code that embeds MoarVM despite the latter not having an embedding interface. That's why I worry only a bit. | 16:37 | |
| What variables do those command line switches set in the code? I think it would be easier setting them in C than trying to find out how to pass those args to MoarVM | 16:42 | ||
| Oh you mean Configure.pl! | 16:44 | ||
| brrt | sorry, i mean: reconfigure with --optimize=0 --debug, build, and rerun your test :-) | ||
| aye | |||
| nine | That I can do :) | ||
| dalek | arVM/even-moar-jit: 8281387 | brrt++ | tools/jit-bisect.pl: Tell reader which frame really is broken |
16:45 | |
|
16:46
cognominal joined
|
|||
| nine | Updated the gist: gist.github.com/niner/dfdb4ef9ce9ac040abc2 | 16:47 | |
| brrt | hmm | 16:48 | |
| doesn't really ring a bell | |||
| jnthn has been fixing leaks recently though | |||
| nine | So maybe MoarVM is now trying to properly free things that I have not set up correctly. | 16:49 | |
| timotimo | interesting, a compunit's gc_free is asploding? | 16:59 | |
| could this have something to do with sharing callsites between things? that's what hoelzro hunted at some point | 17:00 | ||
| hoelzro | I hope that's not it; that was a pain to track down | 17:03 | |
| timotimo | well, a valgrind run might tell us more about this | 17:05 | |
| or even asan | |||
|
17:10
kjs_ joined
|
|||
| dalek | arVM/even-moar-jit: e5a150c | brrt++ | tools/jit-bisect.pl: Silence prove, probe for broken basic block |
17:13 | |
| brrt | this allows me to pinpoint *exactly* which basic block compilcation is wrong for a given test | 17:14 | |
| which is , frame 395, basic block 8, binparse-string | 17:15 | ||
|
17:18
brrt joined
|
|||
| brrt | hmm | 17:18 | |
| next stop | |||
| make jit bytecode dumps comparable | |||
|
17:21
domidumont joined
|
|||
| timotimo | oh yeah | 17:46 | |
|
18:17
kjs_ joined
18:36
kjs_ joined
19:02
Ven joined
19:17
mojca_ joined
20:01
brrt joined
|
|||
| brrt | dalek has disconnected... | 20:24 | |
| anyway, i've pinpointed the exact breakage | |||
| will now ponder a fix | |||
| jnthn | brrt++ | ||
| brrt | anyway, that's not the cool bit | ||
| the cool bit is | |||
| i've automated the pinpointing | |||
| jnthn | \o/ | 20:25 | |
| That *is* cool | |||
| 'cus it'll save a lot of time later | |||
| brrt | thing is, it's probably not the getlex which is wrong | 20:26 | |
| because that one looks right | |||
| hmmm | 20:30 | ||
| the plot thickens | |||
|
20:59
mojca joined
21:04
kjs_ joined
|
|||
| timotimo | aaw, he didn't get to fixing it before leaving? | 21:23 | |
| lizmat | the plot thickens indeed :-( | 21:25 | |
| :-) | |||
| timotimo | yeah | 21:48 | |
|
21:59
kjs_ joined
22:07
kjs_ joined
22:09
brrt joined
|
|||
| timotimo | hooray, less than one garbage collection per frame | 22:26 | |
| *cough* *cough* | |||
| not significantly less, though | |||