|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
| AlexDaniel | night o/ | 00:01 | |
|
00:10
Kaiepi left
06:28
Kaiepi joined
06:48
robertle joined
07:09
domidumont joined
07:16
domidumont left,
domidumont joined
|
|||
| nwc10 | for me, t/spec/S09-typed-arrays/native-int.rakudo.moar | 07:21 | |
| fails currently | |||
| ok 871 - uint array .eager returns identity | 07:22 | ||
| Bytecode validation error at offset 52, instruction 9: | |||
| operand type 160 does not match register type 32 | |||
| in block <unit> at t/spec/S09-typed-arrays/native-int.rakudo.moar line 96 | |||
|
08:02
zakharyas joined
08:13
zakharyas left
08:16
zakharyas joined
08:34
zakharyas left,
zakharyas joined
08:45
domidumont left
08:46
domidumont joined
|
|||
| jnthn | morning o/ | 09:06 | |
| nwc10 | correct! | 09:22 | |
|
10:25
lizmat joined
10:51
zakharyas left
|
|||
| lizmat | only 50 commits until the 10K mark for MoarVM | 11:50 | |
| jnthn | Wow :) | ||
| Alrighty, time to try and work on that inlining thingy | 11:51 | ||
| lizmat | hehe | 11:52 | |
| jnthn | Which I hope will take me a lot less than 50 commits to get right :P | 11:54 | |
|
12:37
brrt joined
|
|||
| brrt | \o | 12:41 | |
| jnthn | o/ brrt | ||
| brrt | ohai jnthn | ||
| i'm in the process of creating a blog post detailing the history of spesh/jit | |||
| based on both our blog posts, and maybe timotimo's and nine's if I can find them | 12:42 | ||
| ehm... maybe you can help me find some :-) | |||
| timotimo | oh, did i make a blog post about spesh? | ||
| lizmat looks forward to result :-) | 12:44 | ||
| brrt | you might have timotimo | ||
| this in response to the comment 'perl6 on moarvm is starting to grow a JIT' :-) | 12:45 | ||
| timotimo | i don't seem to recall... wakelift.de has only been a bloggy-blog for a few months now and there's only my reports on profiling grant work on there so far | ||
| jnthn | brrt: Nice. Mine are all on my 6guts blog. Also there's at least one talk slides that might be worth linking to. | ||
| brrt | oh, yes | 12:47 | |
| Geth | MoarVM/inline-unspecialized: b44135a1d4 | (Jonathan Worthington)++ | src/spesh/inline.c Factor out static frame inlinability checks |
||
| MoarVM/inline-unspecialized: d3b888b27b | (Jonathan Worthington)++ | src/spesh/inline.c Factor out spesh graph inlinability checks |
|||
| jnthn | Hmm, it seems that when the call to MVM_spesh_facts_discover was added, then since we already had code that dealt with usage count setting for inlines, we are probably double-counting usages | 12:57 | |
| Of inlines | |||
| timotimo | mhm, so we keep more than we need to | 13:04 | |
| jnthn | Yeah, it'd frustrate dead code elim | 13:05 | |
| timotimo | should the code from just inlining that builds counts be thrown out since facts_discover is precise? | 13:07 | |
| Geth | MoarVM/inline-unspecialized: fa471f1d8c | (Jonathan Worthington)++ | 3 files Fact discovery determines usage counts Some time ago, a call was added to do fact discovery on inlinees. This process sets usage counts along the way. However, the code to set the usage counts in inlining was also in place, so we doubled all of the counts, which would frustrate dead code elimination possibilities that arise post-inline. ... (6 more lines) |
13:11 | |
| timotimo | that looks good | ||
| just from the amount of insertions vs deletions :) | 13:12 | ||
| jnthn | ;) | ||
| timotimo | ugh, we had a little rainstorm an hour ago, but instead of making it cooler it only made it more humid :| | 13:17 | |
| brrt | shall I tell you something funny | 13:23 | |
| the Netherlands is actually drying out | |||
| timotimo | the joke was always that the netherlands is going to flood, but instead it'll first turn into a desert? | 13:24 | |
| brrt | alternatingly, yes | ||
| Geth | MoarVM/inline-unspecialized: 4ecbafa721 | (Jonathan Worthington)++ | src/spesh/optimize.c Do spesh log of inlines in log_inline |
13:26 | |
| jnthn | hmm, just spotted that optimize_string_equality seems to have debugging fprintf calls left behind | 13:28 | |
| timotimo | aw, crap | 13:29 | |
| gist.github.com/gerad/247799/e5a81...ab45f2d908 i might want to put this into my git repo | 13:30 | ||
| (and change it so it matches printf.*stderr | |||
| oh, but optimize_string_equality starts with "return;" | 13:31 | ||
| so it's not completely bad | 13:32 | ||
| jnthn | So two wrongs do make a right? :P | ||
| timotimo | if C had nestable comments... ;) | ||
|
13:38
brrt left
13:41
brrt joined
|
|||
| jnthn | BOOM segfault! | 13:51 | |
|
13:54
brrt left
|
|||
| jnthn | In deopt. In uninlining. Of course it'd be in uninlining. | 13:57 | |
| lizmat | it just got cooler outside! 29.9 -> 29.8 whee! *sigh* | 14:00 | |
| tadzik laughs in polish | 14:01 | ||
| jnthn | 30 here too | ||
| tadzik | 28! | ||
| jnthn | Tssk, so what on earth is happening with the code_ref_reg that we need for deopt... | 14:02 | |
| timotimo | it's not marked as used? :o | 14:08 | |
| jnthn | Explicitly, including on the new code path | ||
| nwc10 | step away from the keyboard for a while? | ||
| (and test whether the beer is cold) | 14:09 | ||
| jnthn | ooh, could be an existing bug that I've just tickeld | 14:10 | |
| *tickled | |||
| Yeah, I think I see what's happening. We inline more now. | 14:15 | ||
| So probably just hit an existing issue where when we take the bytecode for a candidate and turn it back into a graph, we don't see that the code ref reg is used from that graph | 14:17 | ||
| Alas, that's not a trivial one to fix precisely because we don't know which SSA version to bump the usage count on even if we do know the register. | 14:19 | ||
| ugh, no, that fix didn't help anything :S | 14:25 | ||
| Hmm, well apparently it is triggered and so can help but... | 14:34 | ||
|
14:43
brrt joined
14:49
zakharyas joined
|
|||
| dogbert17 | brrt, do you have any theories with regards to the problem reported yesterday? colabti.org/irclogger/irclogger_log...07-03#l132 | 14:50 | |
| brrt | i have not enough information to answer :-) | 14:55 | |
| i haven't seen it, at any rate | |||
| when does this happen? | 14:56 | ||
| jnthn | ooh, I should tried this earlier | ||
| The deopt crash only happens under JIT | 14:57 | ||
| Not sensitive to EXPR JIT either | |||
| dogbert17 | brrt: the valgrind complaints comes early, before any tests have been run, then it fails with bytecode error on test #76. MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6-valgrind-m t/spec/S02-types/native.rakudo.moar | 15:01 | |
| jnthn | Under the interpreter I get: | 15:04 | |
| Deopt one requested by interpreter in frame '' (cuid '118') | |||
| Will deopt 456 -> 404 | |||
| But then under JIT it's | 15:05 | ||
| Deopt one requested by JIT in frame '' (cuid '118') (4208 -> 404) | |||
| And in the interpreter case we don't have anything to uninline | 15:08 | ||
| Which lends further suggestion to that first number - the current offset - being bogus | |||
| dogbert17 | brrt, here's the complete valgrind output: gist.github.com/dogbert17/d64f0a8e...f33cfb9b19 | 15:10 | |
| jnthn | ahh, think I found it | 15:13 | |
| dogbert17 | spesh related? | 15:15 | |
| Geth | MoarVM/inline-unspecialized: 155f1dfb26 | (Jonathan Worthington)++ | src/spesh/deopt.c Update deopt logging, which bitrotted |
15:18 | |
| jnthn | Yeah, was not updating the deopt annotations properly, so they scribbled bogus offsets into the table | ||
| MasterDuke | jnthn: btw, i updated github.com/japhb/perl6-bench recently so it runs on current rakudo. what's needed to get that daily run that was posted somewhere to moarvm.org back up and running? | 15:21 | |
| dogbert17 | and when will MoarVM/inline-unspecialized be merged? | 15:22 | |
| hmm, perhaps we're discussing two different problems :) | 15:23 | ||
| brrt | jnthn: what did I break | ||
| dogbert17: it would help so much if I actually knew what code was breaking | |||
| oh, I see | 15:24 | ||
| jnthn | brrt: You didn't in my case. :) | 15:25 | |
| brrt: It was a problem that showed up in JIT but could hardly be blamed on JIT after all :) | |||
| Geth | MoarVM/inline-unspecialized: ca51c5e27d | (Jonathan Worthington)++ | src/spesh/inline.c Make sure deopt code ref reg is never eliminated We need this for deopt. In a multi-level inline situation, however, we were at risk of deleting the instruction that set it. |
15:26 | |
| dogbert17 | brrt: what is it that I have failed to provide? (confused) | 15:27 | |
| brrt | up until i saw the valgrind output, I had no idea which script was failing in the first place | 15:28 | |
|
15:28
robertle left
|
|||
| dogbert17 | I see, my comments from yesterday were perhaps a bit vague :) | 15:29 | |
| jnthn | dogbert17: As to how long until inline-unspecialized can be merged: not sure. Having fixed the crash I mentioned a moment ago, it now happily builds/tests NQP (not stresssed, mind) but I get a SEGV during the Rakudo build | 15:34 | |
| Waiting for valgrind to hopefully tell me more :) | |||
| brrt | how the hell are we breaking 'new' | 15:37 | |
| jnthn | Ah, thankfully that was a silly thinko :) | 15:38 | |
| Hmmm... | 15:48 | ||
| Wow, I seem to have managed to have a bug that results in a miscompile of NQP such that it miscompiles Rakudo such that it crashes when compiling a Perl 6 program | 15:53 | ||
| Is it just my head that hurts thinking about this? :) | 15:55 | ||
| Geth | MoarVM/inline-unspecialized: f59335eaa6 | (Jonathan Worthington)++ | 5 files Attempt inlining so-far unspecialized callees Sometimes we know the callee, but there wasn't yet a specialization (or an applicable specialization) performed. If the bytecode is small enough, then we can produce a specialization on demand and try to do an inlining of that. This doesn't yet convey the types of the incoming arguments to the specialization of the callee, so various possible optimizations are still not performed yet. |
15:59 | |
| lizmat | jnthn: broken turtles all the way down :-) | 16:01 | |
| jnthn | Ah, it gets more and less fun simultaneously. Actually it's a mis-compile of Rakudo that takes place, the NQP itself is OK. I was thrown off by the fact that reverting my new opt didn't help things. | 16:04 | |
| But master does work out with just a Rakudo rebuild | |||
| That means it's one of the commits I did in my branch that led up to the optimization itself. | |||
| lizmat | :-( | 16:07 | |
| jnthn | Will soon know if fa471f1d8c is to blame; seems somewhat likely | 16:09 | |
| huh, it isn't | 16:10 | ||
|
16:14
AlexDaniel left
16:16
domidumont left
|
|||
| jnthn | Ahh...I musta done something wrong in my analysis | 16:25 | |
| It *is* the new opt | |||
|
16:28
robertle joined
16:31
scovit left
16:59
domidumont joined
|
|||
| Geth | MoarVM/inline-unspecialized: 64dd94d34e | (Jonathan Worthington)++ | src/spesh/inline.c Cope with inlinees with empty first basic block We could also implement removing those, but it's probably good for the inliner to be robust in the face of them anyway. |
17:03 | |
|
17:06
scovit joined
|
|||
| japhb | .oO( robust in the face of the enemy^Winlinee ) |
17:26 | |
| jnthn | :D | 17:27 | |
| Geth | MoarVM/inline-unspecialized: 8c3859ebd8 | (Jonathan Worthington)++ | src/spesh/inline.c Don't try to inline with a flattening callsite The args processing code never had to handle that case before (it is blocked much earlier, by simply never producing a candidate in that case), and so did completely bogus things. |
17:29 | |
|
17:32
Kaiepi left
17:33
Kaiepi joined
|
|||
| jnthn | Seems far, far better with that patch :-) | 17:36 | |
| Enough for today o/ | 17:40 | ||
|
17:55
Kaiepi left
17:56
Kaiepi joined
18:08
lizmat left
18:10
zakharyas left
18:17
lizmat joined
18:50
brrt left
19:09
domidumont left
19:25
brrt joined
19:47
Kaiepi left,
Kaiepi joined
20:16
AlexDaniel joined
20:35
dogbert17 left
21:04
brrt left
21:10
robertle left
23:05
stmuk joined
|
|||
| Geth | MoarVM: jstuder-gh++ created pull request #893: Display build/commit info on config/make |
23:05 | |