|
00:16
SmokeMachine joined
01:16
nativecallable6 joined,
releasable6 joined,
statisfiable6 joined
01:17
unicodable6 joined,
quotable6 joined
03:06
ilbot3 joined
03:57
squashable6 joined,
bloatable6 joined
04:23
cmcodename joined
|
|||
| cmcodename | ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! www.youtube.com/user/l0de/live CALL 315-505-4666 xtodxduyt: BooK_ nwc10 ilmari[m] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄, | 04:23 | |
|
04:23
VCB85Qsushmi joined
|
|||
| VCB85Qsushmi | ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ LRH IS LIVE NOW!! TODAYS EDITION SLIMER GETS FUCKED IN VEGAS!! www.youtube.com/user/l0de/live CALL 315-505-4666 nrbuckjir: nativecallable6 krunen SmokeMachine ▄▄▄▄▄▄▄▄▄▄▄▄ | 04:23 | |
|
04:31
ConoverIHZT70 joined
07:12
Kaiepi joined
07:58
lizmat joined
08:43
domidumont joined
08:49
domidumont joined
09:14
geospeck joined
10:07
Zoffix joined
|
|||
| 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": jcdav.is/2016/09/01/How-the-JVM-com...r-strings/ | 10:08 | |
| nine | Zoffix: very interesting :) I'd never have guessed that they'd add string operations to the vector instruction sets | 10:16 | |
| geekosaur | good grief. and I thought 8086 indexed instructions were weird. | 10:23 | |
| geekosaur may start calling that monstrosity "JVum" | 10:26 | ||
| 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:11 | |
| Now it ends with a "No exception handler located for return" which sounds quite mundane compared. | 11:13 | ||
| Ah, just another off-by-one | 11:29 | ||
| And NQP builds! | |||
| lizmat | nine++ | 11:32 | |
| nine | And so does rakudo! | 11:33 | |
| lizmat | whee! | 11:34 | |
| nine | There are known test failures when running with MVM_SPESH_NODELAY=1 and MVM_SPESH_BLOCKING=1, aren't there? | 11:43 | |
| lizmat | not sure :-( | 11:50 | |
|
11:53
Zoffix left
12:02
reportable6 joined
12:09
lizmat joined
|
|||
| dogbert17 | nine: yes, don't remember the names exactly only fragments, 'fail' and 'exception' | 12:12 | |
| two test files if memory serves | |||
| dogbert17 reruns test in order to refresh his memory | 12:14 | ||
| nine | There's definitely a remaining issue. | 12:16 | |
| dogbert17 | t/spec/S04-exceptions/fail.t and t/spec/S32-exceptions/misc.rakudo.moar was the ones I was thinking about | 12:22 | |
| 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 | |
| And thus fail tests | |||
| Ideally we'd have the backtrace maker figure out the inlining stuff | |||
| 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:40 | |
| The MVM_spesh_dump of the inliner's graph shows the FH Start annotation, but no GOTO or End | 12:41 | ||
| jnthn | Hm, and it's not in the dead handlers list? | 12:45 | |
| nine | Oooh...I think we're just missing the slot for the inline boundary "handler" in the unreachable handlers list. | 12:49 | |
| I think that's wrong even in master | 12:50 | ||
| And another one down :) | 12:52 | ||
| jnthn: thanks for the hint! | |||
| make test now passes with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 | 12:55 | ||
| And so do the spectests :) with exception of the known backtrace issues of course | 13:06 | ||
| jnthn | \o/ | 13:14 | |
| nine++ # this is great! | |||
| 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 | ||
| And now I have a stable base line to operate from :) | 13:15 | ||
| jnthn | \o/ | ||
| Geth | MoarVM/inline_in_place: de2e56f1b3 | (Timo Paulssen)++ (committed by Stefan Seifert) | 4 files Put inlined blocks between their caller and its succ Previously inlined callees were added to the end of the basic block list. We now put the inlined blocks into the list at the position of the invoke op. However we cannot yet get rid of the goto ops entering and exiting the inlined code as that would lead to odd bugs possibly related to the annotations on these ops. |
13:16 | |
| MoarVM/inline_in_place: a65e624baf | (Stefan Seifert)++ | src/spesh/optimize.c Turn inline_end annotated pointless gotos into no_ops We can't remove them completely as that causes weird deopt issues. But turning them into no_ops should give almost the same benefits without the cost. |
|||
| MoarVM/inline_in_place: 9587a32b8d | (Stefan Seifert)++ | src/spesh/inline.c Move inlinee's handlers to front instead of duplicating inliner's Previously active handlers at the point of the invoke were copied and the inlinee's code surrounded by annotations pointing at those copies. Instead we now move the inlinee's handlers to the top of the table so they will be searched first. This means we have to adjust the indexes of the inliner's annotations but that's actually simpler than the whole copying business. |
|||
| nine | jnthn: what do you think about this small refactor? gist.github.com/niner/70d2d733b1f0...6bae5d552e It's mostly for readability and to bring JITed and non-JITed code paths closer together. | 13:18 | |
| jnthn | nine: Looks sensible to me; think I considered doing that myself, even :) | 13:19 | |
| nine | cool | 13:20 | |
|
14:37
committable6 joined
15:04
AlexDaniel joined
|
|||
| 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 | |
| But replacing the goto with a no_op instead of removing it fixes those. | |||
| 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 | |
| we must not delete those | |||
| nine | timotimo: yes, the difference is really just whether to remove gotos carrying an INLINE_END annotation or replace them by no_ops | 15:16 | |
| timotimo | right, i assume that makes sense :) | 15:17 | |
| 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 | ||
| nine | Btw. the method that gets speshed is 'new' in src/core/Backtrace.pm:84 | ||
| And what's inlined is this implicit block: try X::AdHoc.new(:payload("Died")).throw; | 15:19 | ||
| timotimo | hm, perhaps some kind of bug in the "delete the goto but keep the inline_end annotation" logic? | 15:25 | |
| 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 | |
| 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
16:35
brrt joined
17:15
brrt joined
17:23
coverable6 joined,
benchable6 joined
17:27
zakharyas joined
17:39
bisectable6 joined
18:06
Kaiepi joined
18:17
zakharyas joined,
AlexDaniel joined
18:22
zakharyas joined
18:26
Ven`` joined
18:48
ggoebel joined,
Ven`` joined
19:04
Ven`` joined
19:18
Ven`` joined
19:28
Kaiepi joined
19:39
greppable6 joined
20:11
klapperl joined
20:30
ilmari_ joined
20:35
ilmari joined
20:36
Ven`` joined
20:37
benchable6 joined
20:59
evalable6 joined
23:18
samcv joined
|
|||