github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
dogbert2 jnthn: should I (or you close) github.com/MoarVM/MoarVM/issues/960 now that postrelease-opts is out? 14:02
dogbert2 I closed github.com/MoarVM/MoarVM/issues/960 14:22
jnthn dogbert2: Apparently you ;) 15:01
dogbert2 jnthn: indeed :) 15:18
there are a couple of other issues which I believe have been solved but I can't figure out when atm. E.g. github.com/MoarVM/MoarVM/issues/913 15:21
timotimo you know ... we could speculatively devirtualize reprops in the jit, i.e. check for the STable of an object being one specific pointer, and then immediately dispatch to the known repr op function, otherwise go via the STable to the REPRops and getting that 21:06
timotimo that way we can devirtualize reprops that follow, for instance, p6ogetvc_o, like i'm seeing a couple of times in spesh logs (now that spesh logs contain jit info as well) 21:07
timotimo hm, so we'd be accessing the object's header to find the STable value and check that, as opposed to grabbing the STable, following its pointer, grabbing the REPR, following its pointer, grabbing the REPRop in question, which is likely at a high offset, then calling that 21:12
i wonder what percentage of hit for the cache will make the cost for the extra check & branch go away again
gist.github.com/timo/b01c70e2f7ce4...517e3aee87 21:29
being able to reason about lexicals would be kind of cool 21:30
jnthn timotimo: Hm, but a p6ogetvc_o will have been a getattr, which will have been emitted with a guard if there's a stable type? 21:43
timotimo i mean the return value, which doesn't necessarily have a const stable 21:45
jnthn Hm, I might be missing the point; mine was that getattr's return value is logged and guarded if stable (and the guard is used for something) 21:47
timotimo oh, OK 21:48
i should check for places in the spesh log where something after a getattr where the return value does get an op devirted on it
oh, i'll push a WIP of the "some jit stuff goes in the spesh log" modification
i'm not happy with the results yet, but it's already interesting 21:49
jnthn heh, that code snippet could sure benefit from GVN or CSE or whichever
It's loading and guarding the newval lexical 3 times?! 21:50
Geth MoarVM/jit_stuff_in_speshlog: 9332dcd605 | (Timo Paulssen)++ | 3 files
output "After" spesh log after jit, for comments

now comments can be added by the jit and still end up in the spesh log. Currently it outputs what instructions bail the jit, which end the exprjit compiler in the middle of a BB, what repr ops get devirtualized or not.		 21:51
timotimo newval is, interestingly enough, a parameter to the block
jnthn ooh 21:52
timotimo++ # that's really nice info to have in the spesh log
timotimo \o/
jnthn In fact, that's probably 99% of my use of the JIT log :)
timotimo we talked about this a long time ago, or at least it feels like that
jnthn :)
timotimo i just somehow procrastinated this pretty simple task for so long 21:53
Geth MoarVM/jit_stuff_in_speshlog: d854292c8e | (Timo Paulssen)++ | src/spesh/dump.c
also output comments on PHI nodes

which is almost exclusively "begin of exprjit" comments, but still.		 21:54
MasterDuke anybody have any thoughts on github.com/MoarVM/MoarVM/pull/970 ? 23:15
Geth MoarVM: faea0aecc8 | (Daniel Green)++ (committed by timo) | 4 files
Convert expmod_I to allocate in called function
 23:28
MoarVM: 1325e4ca68 | (Daniel Green)++ (committed by timo) | src/core/interp.c
Make *_I ops in interp.c consistent
MasterDuke timotimo: cool, thanks 23:31
timotimo i wonder what other _*I ops can benefit from a special path in the jit for smallbigint 23:32
like, maybe coerce_nI?
MasterDuke timotimo: instead of the jit just calling MVM_bigint_from_num like it does now? 23:53
timotimo yeah, if the value is in range for a 64 bit integer it could instead do it right then and there 23:54
but i don't know how expensive that check is
maybe we could log what values coerce_nI is being called with typically in some choice programs 23:55
MasterDuke oO(if only we had a comprehensive benchmark suite we could instrument for such a purpose...) 23:58

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!