| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:02 sena_kun joined 00:04 Altai-man_ left 02:01 Altai-man_ joined 02:04 sena_kun left 04:02 sena_kun joined 04:04 Altai-man_ left
Geth MoarVM/disp-prog-spesh-codegen: 10 commits pushed by (Timo Paulssen)++
timotimo ^- a rebase on latest new-disp as well as the Load* ops for dispatch program 04:27
nine Yeah, we can't merge inlined and non-inlined BBs unfortunately 05:34
timotimo what prevents us from that? only that we rely on the BB->is_inlined boolean?
nine I no longer know exactly :( I'd guess deoptimization 05:35
I wonder if we can't generate better code for handling those small ints and uints in the first place. Those superfluous operations like boxing just to unbox and truncate followed by extend are often just an artifact of how QASTOperationsMAST and QASTCompilerMAST are structured 05:39
In a way they are just like the lego JIT. They only look at one op at a time and miss the big picture. 05:40
timotimo aye 05:41
would be nice to get rid of those up front, but the most juicy pairs of box and unbox are across inline boundaries 05:48
nine Well....of course...returning a value is why we need a box in the first place :/ 05:54
timotimo we already have invoke_i and return_i, they just don't appear all that often in the end 05:55
nine why is that?
timotimo not exactly sure 05:56
nine I guess because NQP doesn't let us declare a return type? 06:01
Anyway, gotta go. Fitness training starts at 8:30 and then it's time for some air time :)
timotimo o/
06:01 Altai-man_ joined
nine And I dare say, you should get some slepp :D 06:02
timotimo asleep has been bad
06:04 sena_kun left
nwc10 good *, #moarvm 06:37
nine: presumably "artifact of how QASTOperationsMAST and QASTCompilerMAST are structured" stops being an issue once Q becomes R
08:03 sena_kun joined 08:04 Altai-man_ left 10:01 Altai-man_ joined 10:04 sena_kun left 10:08 zakharyas joined 10:23 zakharyas left 12:02 sena_kun joined 12:04 Altai-man_ left 13:05 linkable6 joined 13:07 evalable6 joined 13:23 lucasb joined 14:02 Altai-man_ joined 14:05 sena_kun left 15:16 zakharyas joined
nwc10 evil GC ate my hash key 15:31
(need to go out and eat)
but what I do know is that something adds the string "src/vm/moar/stage0/QRegex.moarvm" as a hash key in tc->instance->loaded_compunits 15:32
and the string came from the nursery
whereas all previous strings added to it were in gen2
and I suspect that this has *never* mattered before
but if I have it right, the keys of tc->instance->loaded_compunits are only added to the GC roots on a full GC run 15:33
but in master, this doesn't matter, because nothing raelly cares *too* hard about the keys in that hash
and anyway, we know that some of our key comparisons are buggy, and the 64 bit hash saves us
16:02 sena_kun joined 16:04 Altai-man_ left 16:40 zakharyas left
timotimo it occured to me earlier when i was in bed that dispatch chains could/should also be the right mechanism to have specialized functions for reprops based on the type, like instead of MVMArray's at_pos we would have at_pos_i64, at_pos_i32, at_pos_i16, etc etc 17:53
there will have to be something that knows all these functions, but it could probably actually be implemented in C like all the things in disp/boot.c 17:55
18:02 Altai-man_ joined 18:05 sena_kun left
nwc10 no, I should read my debugging more carefully. Some previous keys were in the nursery. But this one gets unlucky. 19:18
investigating further
19:32 zakharyas joined 20:02 sena_kun joined 20:04 Altai-man_ left
nwc10 D'oh 20:14
iterator terminated early for $reasons 20:16
(It did not have the correct kompromat) 20:17
21:10 zakharyas left 22:01 Altai-man_ joined 22:04 sena_kun left 23:26 vrurg left 23:27 vrurg joined