github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
03:00 lucasb left 03:56 sena_kun joined 04:43 sena_kun left 05:44 domidumont joined 06:13 domidumont left 07:26 robertle joined 07:47 domidumont joined 08:46 dogbert17 left 08:58 sena_kun joined 09:31 zakharyas joined 09:50 zakharyas left 10:00 domidumont left
Geth MoarVM: 38915b934d | (Jonathan Worthington)++ | 4 files
Tweak spesh logging's new compunit handling/quotas

The mechanism to put a new spesh log in place when we see a new compilation unit is helpful for making sure we do decently at OSR for program mainlines. However, it was not so well engineered; recent Rakudo changes made it start to miss out on optimizing some programs, but it also turned out to be to blame for #968. Tune the mechanism, thus ... (5 more lines)
10:04
10:25 zakharyas joined 11:41 zakharyas left 11:48 domidumont joined, domidumont left 11:49 domidumont joined 11:55 lucasb joined 12:04 Guest15407 joined
Guest15407 is trying to reproduce the last/latest fromspace bug 13:32
13:41 zakharyas joined
Geth MoarVM: 1fd0fdcd68 | (Jonathan Worthington)++ | 8 files
Fix stack simulation losing track in some cases

When we had specialized code calling unspecialized code, it was possible for the stack in the specializer's stack simulation to keep on growing. This made searches on it far more costly, not to mention increasing memory use (though bounded to the point that the unspecialized code got to being specialized, so it wasn't unbounded). Make sure that we log enough to know to take such frames away again. Fixes #1060.
13:46
MoarVM/frame-opts: f7aecd905b | (Jonathan Worthington)++ | 12 files
Only create arg processing context if needed

Most specialized frames do not need it, since they rewrite their argument processing code into something far cheaper. We can also save the cost of cleaning it up afterwards. On a benchmark doing quite a lot of non-inlinable calls, this saved ~2% of the total CPU cycles, as measured by callgrind.
13:55
MoarVM/frame-opts: 72fb2f3305 | (Jonathan Worthington)++ | src/moar.c
Make MVM_HASH_RANDOMIZE properly control hash rand

Before, if one set it to 0, some randomization could still happen. The sure-fire way to make sure that doesn't happen is to just fix the hash secrets to 0 also.
MoarVM/frame-opts: 676a6ed0c0 | (Jonathan Worthington)++ | 8 files
Avoid having to NULL ->extras on each frame

By using ->flags instead. This saves us at least one CPU instruction per call frame creation.
13:56
14:02 squashable6 left 14:03 squashable6 joined
Geth MoarVM: 5f177f5828 | (Jonathan Worthington)++ | src/moar.c
Make MVM_HASH_RANDOMIZE properly control hash rand

Before, if one set it to 0, some randomization could still happen. The sure-fire way to make sure that doesn't happen is to just fix the hash secrets to 0 also.
14:09
MoarVM/frame-opts: 18654e8c32 | (Jonathan Worthington)++ | 12 files
Only create arg processing context if needed

Most specialized frames do not need it, since they rewrite their argument processing code into something far cheaper. We can also save the cost of cleaning it up afterwards. On a benchmark doing quite a lot of non-inlinable calls, this saved ~2% of the total CPU cycles, as measured by callgrind.
MoarVM/frame-opts: e2b8aa10fe | (Jonathan Worthington)++ | 8 files
Avoid having to NULL ->extras on each frame

By using ->flags instead. This saves us at least one CPU instruction per call frame creation.
14:10
timotimo i see this latest one is a rebase, i *thought* i had already seen at least one of these commits before
jnthn I then re-ordered the branch so I could pick out the first commit into master, since it's not really related to what's in the branch at all, and helpful otherwise 14:11
timotimo OK, that makes sense 14:21
jnthn There's something wrong with at least one of the two commits in that branch 14:23
Going to have a got at github.com/rakudo/rakudo/issues/3114 first though
Geth MoarVM: cf3b545e53 | (Jonathan Worthington)++ | 3 files
Reinstate callsite during uninlining

This fixes the bug in github.com/rakudo/rakudo/issues/3114. It's possible that there may be situations that need a more complete args processing context too, but for the crash in question this is sufficient.
15:02
15:26 zakharyas left 15:39 domidumont left 15:52 robertle left 16:23 domidumont joined, domidumont left 16:24 domidumont joined 17:00 robertle joined 17:06 zakharyas joined 17:14 domidumont left 17:22 domidumont joined 17:24 domidumont left 18:16 domidumont joined 18:19 domidumont left 18:32 Elronnd joined 18:38 zakharyas left 18:43 zakharyas joined 18:58 dogbert17 joined 19:13 zakharyas left
Kaiepi building moarvm with clang generates 49 warnings on my machine, but i don't really have the time to fix them for a couple weeks 20:01
timotimo surely in part my fault for being a little sloppy with fprint macros 20:11
20:12 brrt joined 20:31 MasterDuke joined
Elronnd even just including the headers generates quite a few warnings 20:33
timotimo can you paste them somewhere?
Elronnd sure, one sec 20:34
a bunch of them are unused static inline functions, which is maybe not much of a concern but would still be nice to do something about
Geth MoarVM/expr-jit-devirtualize: 4 commits pushed by (Bart Wiegmans)++ 20:36
timotimo well, if you only include headers, the static inline functions surely won't be used at all
Elronnd yes
0x0.st/zJTV.txt
21:04 lucasb left 21:17 sena_kun left 21:25 japhb left 21:47 japhb joined 22:44 brrt left