Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2018-01-07

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:16 SmokeMachine joined #moarvm
01:16 nativecallable6 joined #moarvm
01:16 releasable6 joined #moarvm
01:16 statisfiable6 joined #moarvm
01:17 unicodable6 joined #moarvm
01:17 quotable6 joined #moarvm
03:06 ilbot3 joined #moarvm
03:06 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:57 squashable6 joined #moarvm
03:57 bloatable6 joined #moarvm
04:23 cmcodename joined #moarvm
04:23 cmcodename ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 xtodxduyt: BooK_ nwc10 ilmari[m] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄,
04:23 VCB85Qsushmi joined #moarvm
04:23 VCB85Qsushmi ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! https://www.youtube.com/user/l0de/live CALL 315-505-4666 nrbuckjir: nativecallable6 krunen SmokeMachine ▄▄▄▄▄▄▄▄▄▄▄▄
04:31 ConoverIHZT70 joined #moarvm
07:12 Kaiepi joined #moarvm
07:58 lizmat joined #moarvm
08:43 domidumont joined #moarvm
08:49 domidumont joined #moarvm
09:14 geospeck joined #moarvm
10:07 Zoffix joined #moarvm
10:08 Zoffix Saw this. Didn't read. But Mentioning in case it's useful: "How the JVM compares your strings using the craziest x86 instruction you've never heard of": http://jcdav.is/2016/09/01/How-the-JVM-compares-your-strings/
10:16 nine Zoffix: very interesting :) I'd never have guessed that they'd add string operations to the vector instruction sets
10:23 geekosaur good grief. and I thought 8086 indexed instructions were weird.
10:26 * geekosaur may start calling that monstrosity "JVum"
11:11 nine Wow...turns out the infiniloop was caused by an off-by-one error when moving existing handlers to make space for the inlinee's handlers. I deem it a miracle that it didn't explode much earlier and much more violent.
11:13 nine Now it ends with a "No exception handler located for return" which sounds quite mundane compared.
11:29 nine Ah, just another off-by-one
11:29 nine And NQP builds!
11:32 lizmat nine++
11:33 nine And so does rakudo!
11:34 lizmat whee!
11:43 nine There are known test failures when running with MVM_SPESH_NODELAY=1 and MVM_SPESH_BLOCKING=1, aren't there?
11:50 lizmat not sure :-(
11:53 Zoffix left #moarvm
12:02 reportable6 joined #moarvm
12:09 lizmat joined #moarvm
12:12 dogbert17 nine: yes, don't remember the names exactly only fragments, 'fail' and 'exception'
12:12 dogbert17 two test files if memory serves
12:14 * dogbert17 reruns test in order to refresh his memory
12:16 nine There's definitely a remaining issue.
12:22 dogbert17 t/spec/S04-exceptions/fail.t and t/spec/S32-exceptions/misc.rakudo.moar was the ones I was thinking about
12:36 jnthn nine: The failures I'm aware of in spectest with those flags are due to us not including inlined frames when we produce backtraces, and so they come out too short in some cases
12:36 jnthn And thus fail tests
12:36 jnthn Ideally we'd have the backtrace maker figure out the inlining stuff
12:40 nine Huh!? The "failed to fix up handler" error I'm investigating is due to missing GOTO and FH End annotations for a PROCEED handler. But those are missing even before we inline anything.
12:41 nine The MVM_spesh_dump of the inliner's graph shows the FH Start annotation, but no GOTO or End
12:45 jnthn Hm, and it's not in the dead handlers list?
12:49 nine Oooh...I think we're just missing the slot for the inline boundary "handler" in the unreachable handlers list.
12:50 nine I think that's wrong even in master
12:52 nine And another one down :)
12:52 nine jnthn: thanks for the hint!
12:55 nine make test now passes with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1
13:06 nine And so do the spectests :)  with exception of the known backtrace issues of course
13:14 jnthn \o/
13:14 jnthn nine++ # this is great!
13:14 nine Note that I haven't activated the removal of pointless gotos yet. But that should be much more straight forward than before your refactor
13:15 nine And now I have a stable base line to operate from :)
13:15 jnthn \o/
13:16 Geth ¦ MoarVM/inline_in_place: de2e56f1b3 | (Timo Paulssen)++ (committed by Stefan Seifert) | 4 files
13:16 Geth ¦ MoarVM/inline_in_place: Put inlined blocks between their caller and its succ
13:16 Geth ¦ MoarVM/inline_in_place:
13:16 Geth ¦ MoarVM/inline_in_place: Previously inlined callees were added to the end of the basic block list.
13:16 Geth ¦ MoarVM/inline_in_place: We now put the inlined blocks into the list at the position of the invoke op.
13:16 Geth ¦ MoarVM/inline_in_place: However we cannot yet get rid of the goto ops entering and exiting the inlined
13:16 Geth ¦ MoarVM/inline_in_place: code as that would lead to odd bugs possibly related to the annotations on
13:16 Geth ¦ MoarVM/inline_in_place: these ops.
13:16 Geth ¦ MoarVM/inline_in_place: review: https://github.com/MoarVM/MoarVM/commit/de2e56f1b3
13:16 Geth ¦ MoarVM/inline_in_place: a65e624baf | (Stefan Seifert)++ | src/spesh/optimize.c
13:16 Geth ¦ MoarVM/inline_in_place: Turn inline_end annotated pointless gotos into no_ops
13:16 Geth ¦ MoarVM/inline_in_place:
13:16 Geth ¦ MoarVM/inline_in_place: We can't remove them completely as that causes weird deopt issues. But turning
13:16 Geth ¦ MoarVM/inline_in_place: them into no_ops should give almost the same benefits without the cost.
13:16 Geth ¦ MoarVM/inline_in_place: review: https://github.com/MoarVM/MoarVM/commit/a65e624baf
13:16 Geth ¦ MoarVM/inline_in_place: 9587a32b8d | (Stefan Seifert)++ | src/spesh/inline.c
13:16 Geth ¦ MoarVM/inline_in_place: Move inlinee's handlers to front instead of duplicating inliner's
13:16 Geth ¦ MoarVM/inline_in_place:
13:16 Geth ¦ MoarVM/inline_in_place: Previously active handlers at the point of the invoke were copied and the
13:16 Geth ¦ MoarVM/inline_in_place: inlinee's code surrounded by annotations pointing at those copies. Instead
13:16 Geth ¦ MoarVM/inline_in_place: we now move the inlinee's handlers to the top of the table so they will be
13:16 Geth ¦ MoarVM/inline_in_place: searched first. This means we have to adjust the indexes of the inliner's
13:16 Geth ¦ MoarVM/inline_in_place: annotations but that's actually simpler than the whole copying business.
13:16 Geth ¦ MoarVM/inline_in_place: review: https://github.com/MoarVM/MoarVM/commit/9587a32b8d
13:18 nine jnthn: what do you think about this small refactor? https://gist.github.com/niner/70d2d733b1f0310ef8df986bae5d552e  It's mostly for readability and to bring JITed and non-JITed code paths closer together.
13:19 jnthn nine: Looks sensible to me; think I considered doing that myself, even :)
13:20 nine cool
14:37 committable6 joined #moarvm
15:04 AlexDaniel joined #moarvm
15:11 nine Odd...despite all the changes, I still cannot remove the goto at the end of the inlined code. And even though the annotations are all correctly moved elsewhere, I get odd errors.
15:11 nine But replacing the goto with a no_op instead of removing it fixes those.
15:15 timotimo you're only removing the gotos at the end of inlines, right? because there's also gotos that may seem useless after a jumplist instruction
15:15 timotimo we must not delete those
15:16 nine timotimo: yes, the difference is really just whether to remove gotos carrying an INLINE_END annotation or replace them by no_ops
15:17 timotimo right, i assume that makes sense :)
15:18 nine I'm already more cauteous than master by not removing a goto that's the only instruction in a BB
15:18 timotimo right
15:18 nine Btw. the method that gets speshed is 'new' in src/core/Backtrace.pm:84
15:19 nine And what's inlined is this implicit block: try X::AdHoc.new(:payload("Died")).throw;
15:25 timotimo hm, perhaps some kind of bug in the "delete the goto but keep the inline_end annotation" logic?
15:33 nine The Inline End annotation is moved correctly to the last of the remaining instructions (a "set"). Same true for the FH End (0). That handler is just the INLINE_BOUNDARY anyway.
15:33 nine I don't see anything about this cuid in the deopt log either. So what could depend on that goto being there?
16:04 Kaiepi joined #moarvm
16:35 brrt joined #moarvm
17:15 brrt joined #moarvm
17:23 coverable6 joined #moarvm
17:23 benchable6 joined #moarvm
17:27 zakharyas joined #moarvm
17:39 bisectable6 joined #moarvm
18:06 Kaiepi joined #moarvm
18:17 zakharyas joined #moarvm
18:17 AlexDaniel joined #moarvm
18:22 zakharyas joined #moarvm
18:26 Ven`` joined #moarvm
18:48 ggoebel joined #moarvm
18:48 Ven`` joined #moarvm
19:04 Ven`` joined #moarvm
19:18 Ven`` joined #moarvm
19:28 Kaiepi joined #moarvm
19:39 greppable6 joined #moarvm
20:11 klapperl joined #moarvm
20:30 ilmari_ joined #moarvm
20:35 ilmari joined #moarvm
20:36 Ven`` joined #moarvm
20:37 benchable6 joined #moarvm
20:59 evalable6 joined #moarvm
23:18 samcv joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary