github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:17 MasterDuke left 01:09 MasterDuke joined, MasterDuke left, MasterDuke joined
Geth MoarVM/inline_smart_coerce_methodcalls: 56379415dc | (Timo Paulssen)++ | src/spesh/optimize.c
Turn smrt_strify/_numify Into Method Calls

and potentially inline them immediately.		 01:28
timotimo (just forcepushed to fix the commit message)
MasterDuke timotimo: that'll just need a minor change to support smrt_intify, correct? 01:37
timotimo yeah 01:39
does smrt_intify live in your repo or in moarvm/moarvm?
and the whole nqp-with-int-by-defaults tuff
MasterDuke they're all in my repo. i did make a PR for moarvm a day or two ago, currently working on cleaning up the nqp branch to PR it 01:40
timotimo hum. annoyingly the comment i'm trying to put into the spesh graph for when a smrt_*ify gets turned into a method call doesn't stick around
MasterDuke github.com/MoarVM/MoarVM/pull/1038 if anyone wants to review
timotimo recently when looking at PRs i have made but haven't merged i saw that i was trying to make decont on proxies a spesh plugin related thing 01:42
say, do you think we should perhaps use one of the deprecated ops for new ops by now? 01:43
i think they have been in there for graceful explosivity for a long time 01:44
that way the diffs for new ops isn't as gigantic either
MasterDuke huh, i don't think i've ever seen an error about using a deprecated op 01:46
timotimo say, do you get a lot of "Couldn't safely determine ..." outputs in the spesh log?
MasterDuke all the time? or when doing something in particular?
timotimo just in general
i think we'll also want to put BOOTHash into the cheating list 01:47
MasterDuke don't really remember seeing that a lot
timotimo but did you grep for it? :P
MasterDuke heh, i did not 01:48
timotimo how would you feel about replacing the lowest-numbered DEPRECATED op with smrt_intify?
MasterDuke what cheating list (re BOOTHash)?
timotimo the one in spesh that also contains BOOTInt and BOOTNum or whatever 01:49
BOOTInt, BOOTNum, and BOOTStr
for some reason they don't make it clear that they don't have these methods, so the optimization would always fall flat on them 01:50
MasterDuke in my PR? 01:51
timotimo the cheating list already existed before your PR 01:52
MasterDuke will i have to rebootstrap nqp if i replace a DEPRECATED with smrt_intify? 01:53
timotimo i don't think so, no
MasterDuke k 01:54
btw, why just BOOTHash and not all the BOOT*s?
timotimo i've gone and collected spesh logs of the entire nqp build and that's the only one that showed up :) 01:55
MasterDuke ah 01:56
timotimo curiously, int also shows up
MasterDuke oh, while i'm looking at the oplist
timotimo not sure how that's happening
MasterDuke i have intify with `:pure :invokish :deoptallpoint :deoptonepoint :maycausedeopt :specializable`, but (num|str)ify only have `:pure :invokish :maycausedeopt :specializable` 01:57
should `:deoptallpoint :deoptonepoint` be added to them? 01:58
timotimo those are prerequisites for the method call optimization i recently made
they aren't yet in master because that opt is waiting for the next release
MasterDuke so do them seperately after that's merged? 01:59
timotimo yeah, probably together with the changes to the spesh function that adds intify support to the method call optimization 02:00
MasterDuke k
timotimo: force pushed a change to replace DEPRECATED_1 instead of putting it at the end 02:05
timotimo oh wow
the diff actually became a whole lot bigger because the array in Ops.nqp actually has all operands in a row
maybe there's a different deprecated op that actually has the same amount of operands as the smrt_intify one 02:06
that'd hopefully give the small diff that i was hoping for
MasterDuke should that BOOTHash addition go in with my PR? or be a seperate change? 02:07
timotimo let's make it a separate change
MasterDuke testing it now 02:13
Geth MoarVM: MasterDuke17++ created pull request #1040:
Add BOOTHash to spesh cheat list		 02:32
timotimo i think i'll go to bed very soon now 02:43
02:56 Kaiepi left 02:59 Kaiepi joined 03:01 Kaypie joined, Kaiepi left 03:05 Kaypie left 03:09 Kaiepi joined 03:22 Kaypie joined, Kaiepi left 03:48 ufobat_ joined 03:52 ufobat__ left 07:41 domidumont joined 11:39 AlexDaniel left
nine timotimo: I can't find any special handling of profiler ops in the inliner's bytecode size determination. The spesh log also shows a frame size of 1094 bytes with enabled profiler vs. 369 bytes without. 12:57
13:39 AlexDaniel joined 13:41 lizmat joined
timotimo nine: yeah, i have a PR that has an unresolved change request from you for this ;) 13:55
MasterDuke there are a bunch of MoarVM PRs that should be looked over 14:06
nine timotimo: I'm suddenly much more interested in seeing that merged *g* 14:09
timotimo i'll have to put in more features to update_ops :| 14:11
14:49 Ven`` joined
timotimo MasterDuke: better candidates for replacement with smrt_intify are DEPRECATED_34, DEPRECATED_24, DEPRECATED_17, DEPRECATED_22, DEPRECATED_13, DEPRECATED_32 (maybe the best of them all), DEPRECATED_4 (the oldest of the candidates), and a few more 14:52
14:59 MasterDuke left 15:03 domidumont left 15:50 Kaypie left 15:51 Kaypie joined 15:54 domidumont joined 16:11 domidumont left 17:06 Ven`` left 17:09 zakharyas joined, AlexDaniel left 17:54 domidumont joined 18:50 MasterDuke joined, MasterDuke left, MasterDuke joined
MasterDuke timotimo: github.com/MoarVM/MoarVM/pull/1038 updated 18:58
yoleaux 18:19Z <moritz> MasterDuke: github.com/moritz/perl6-all-module...cpan/JNTHN looks much better now
timotimo yes, that's what i'm talking about! \o/
MasterDuke .tell moritz nice, i use perl6-all-modules a lot and that helps 18:59
yoleaux MasterDuke: I'll pass your message to moritz.
timotimo i think after that PR goes in, it'd probably be good to give most of the functions in coerce.h an MVM_PUBLIC, even though we don't really have users per se 19:00
19:00 Kaypie left
MasterDuke i could see that 19:02
19:02 Kaiepi joined
timotimo i gave the PR a review :) 19:04
the nqp branch will surely not be as easy a review as this one X_x 19:07
MasterDuke thanks 19:15
19:44 domidumont left 19:48 domidumont joined, domidumont left
MasterDuke it turns out i was not 100% consistent in literal notation in NQP and Rakudo, e.g., changing `1` to `1.0` vs `1e0`. anybody have a preference? is there a difference in NQP? 19:50
timotimo how do you mean? 19:51
nqp doesn't have rats at all
so the only thing that 1.0 can be is a num
MasterDuke that's what i was thinking (and i prefer 1.0 over 1e0), but thought i should poll 19:55
20:40 lizmat_ joined 20:43 lizmat left 20:55 lizmat_ left 20:58 lizmat joined 20:59 patrickb joined 21:02 Kaiepi left 21:07 Kaiepi joined 21:08 patrickb left 21:15 Kaypie joined, Kaiepi left 21:46 zakharyas left 22:10 ufobat_ left
japhb MasterDuke: I prefer 1e0 to reduce confusion for people that have to work across layers (and that would be basically anyone who is looking at the NQP source code, I would think). Plus which, after the intify work, aren't there going to be only a few num constants in NQP? 22:47
timotimo i've got a benchmark that has a high percentage of hits in spesh's arg guard run function 23:49
i wonder if we should perhaps put computed goto in there, too? 23:50
(also at some point they can be jit-compiled, too)

Powered by Cro and the Raku® Programming Language.

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

Thank you!