github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo heck yeah! 00:16
i see Str being inlined into what used to be a smrt_strify 00:17
jnthn Well, that sounds nice :) 00:18
timotimo++
Though since we're just before a release (I think?), maybe a branch that we merge right afterwards (provided it passes tests)? 00:19
timotimo of course
it'll hit .Str of NQPGrammar and NQP::Regex and friends!
i'll extra-check what types are being optimized for 00:20
it should also hit .Str on hash iterators
ok, only NQP::Regex, NQPRegex, and NQP::Grammar at the moment 00:22
jnthn That could still be quite a win 00:23
Those are probably all over the grammar
*compiler
Well, probably the grammar too :)
timotimo OK, the hash iterator only gets strified with smrt_strify in SET_BLOCK_OUTER_CTX, which never gets speshed at all, in compile_node, which has barely any hits, and in local. also in !precompute_nfas 00:35
i wonder why type "int" returns -1 for "do you have a .Num method?", i.e. the cache doesn't consider itself authoritative? 00:40
AlexDaniel jnthn: btw have you seen this? github.com/rakudo/rakudo/issues/2623 00:52
timotimo Stage optimize : MoarVM oops: Spesh inline: unhandled case of return_o 01:02
well, that's not fun
sounds like it's missing code-gen for automatic boxing on return
would be nice if it didn't cause an oops, though :) 01:03
timotimo i wonder how this case of return mismatch blew up but otherwise it never does? hmm. 01:21
maybe all rakudo ever does is return_o?! 01:46
or maybe there's just one .Str or .Int that returns an object, which makes sense in rakudo land where Str is a thing
MasterDuke timotimo: around? 02:06
timotimo ya 02:10
MasterDuke so i made a change for intify, but the optimize_coerce function isn't being called because of an intify, but a numify when the blow up happens 02:12
in fact, it doesn't get called because of an intify at all before the nqp build dies
MasterDuke gist.github.com/MasterDuke17/a618b...d984af2d3e has my most recent change 02:14
and this is what happens gist.github.com/MasterDuke17/c1ea4...5d2f84f48f 02:15
timotimo ugh i wish i could just click and get the context of the original file in that diff
MasterDuke heh 02:16
timotimo can you give me a diff with a higher -u number?
sorry
-U
MasterDuke should i just put the whole thing in also
timotimo like, 25 mybe?
it's still useful to have the colors from the diff in the middle
MasterDuke -U10 good? 02:17
timotimo 25
MasterDuke gist updated 02:18
timotimo Perl6-Optimizer's simplify_refs is the only case ever where it gets a return_o that hits an invoke_n/i/s
ah!
guess what
the code i had in there was wrong
if (is_strify && ss->can_box & MVM_STORAGE_SPEC_CAN_BOX_STR) { 02:19
MasterDuke yay?
timotimo + else if (is_intify && ss->can_box & MVM_STORAGE_SPEC_CAN_BOX_INT) {
these have to change
if (is_strify && (ss->can_box & MVM_STORAGE_SPEC_CAN_BOX_STR)) {
and
else if (is_intify && (ss->can_box & MVM_STORAGE_SPEC_CAN_BOX_INT)) {
i've done this mistake multiple times in the past, and if i don't better myself i'll do it again :( 02:21
anyway, this could have caused issues
MasterDuke oh! i did at least once get into the intify branch during the nqp build, but it still dies with the same error 02:23
timotimo well, it's good to know at least that it's not this problem 02:24
oh 02:28
the first if in that function also seems to have that bug with & mixed with &&
MasterDuke same error 02:30
timotimo can you shoot the spesh log my way? 02:32
MasterDuke for just the part that dies assume?
timotimo yeah, rxjump, right? 02:34
MasterDuke hm, when run by itself with a spesh log it doesn't seem to want to die.... 02:35
ok, does first time with BLOCKING=1
timotimo good 02:36
MasterDuke gist.github.com/MasterDuke17/8eaff...c0c269fd1e 02:38
timotimo huh, do i take the one or the other? 02:39
MasterDuke the .zstd
other was a typoo 02:40
timotimo OK, so 02:43
it's a smrt_intify
it turns into an unbox_n, because it's called on a Num object
the num register goes immediately into the position argument of bindpos_o
MasterDuke huh. why don't i see a smrt_intify in my stderr output? 02:44
timotimo i'll leave that for you to figure out %)
i'll probably go sleep real soon
but yeah, look at line 1465451 02:45
that's the get_n that pulls the num out of the BOOTNum object it creates just above
MasterDuke ok. btw, is my is_intify branch correct? i really just need those two lines? 02:46
timotimo it looks like it started as a smrt_numify on a VMArray, that got turned into elems + coerce_in
i think it is
do you have a clue how you'll be able to fix this problem?
MasterDuke not really. i haven't actually changed the numify branch at all, so i don't know why it's developed a problem 02:47
but i also haven't spent much time on it yet
if i figure something out tonight i'll leave you a note 02:49
timotimo the smrt_intify turns into an unbox_n but no coerce_in, why? :\
we don't have an is_numify && (ss->can_box & ...) thing that'd build an unbox_i 02:50
judging from the stderr output it looks like it's thinking it's got a smrt_numify when it actually has a smrt_intify?
can you output all three is_...ify variables? 02:51
MasterDuke where?
timotimo if there's more than one that's 1, that'd be strange trouble
hm, no, that can't actually happen though?
how about this, set a conditional breakpoint in optimize_smart_coerce under the condition that is_intify is true, then see what path it takes 02:52
oh
} else if(ss->can_box & (MVM_STORAGE_SPEC_CAN_BOX_NUM | MVM_STORAGE_SPEC_CAN_BOX_INT)) {
MVMuint16 register_type =
ss->can_box & MVM_STORAGE_SPEC_CAN_BOX_INT ? MVM_reg_int64 : MVM_reg_num64;
these lines there
this code isn't right any more 02:53
it'll trigger for the num case, but there's nothing in it for handling unboxing to an int register
it's only got logic for str vs int 02:54
errr, str vs num
as the target
MasterDuke hmm
timotimo it'll always generate an unbox_i or unbox_n depending on what kind of object is being smrt_strify'd or smrt_numify'd 02:55
MasterDuke ah, intead of what is being done to it
timotimo and then if the object boxes a num, it'll generate a coerce_ns, otherwise a coerce_is if it's a smrt_strify, and a set or coerce_in otherwise 02:56
i think that's the exact point it goes wrong
it just things "not strify must mean numify"
thinks*
MasterDuke i'll play around there
timotimo i think register_type will always™ be right 02:57
MasterDuke hm, adding `else if (is_intify) new_ins->info = MVM_op_get_op(register_type == MVM_reg_num64 ? MVM_OP_coerce_in : MVM_OP_set);` didn't fix anything 03:00
timotimo i think it has to be ni rather than in? 03:01
MasterDuke oh hey! nqp built 03:03
now to take out those prints which just slow things down...
timotimo sweet
MasterDuke timotimo++
MasterDuke_ ugh, my laptop battery is just not working well at all 03:10
timotimo d'oh
Geth MoarVM/inline_smart_coerce_methodcalls: f30a806fc5 | (Timo Paulssen)++ | src/spesh/inline.c
Teach Spesh Inline About Returning By Unboxing

Needed whenever an inlinee has a return_o op that matches up to an invoke_i/n/s in the inliner.
Interestingly, seems to only happen once during the entirety of rakudo's build process: in the ... (6 more lines)
03:13
MoarVM/inline_smart_coerce_methodcalls: a2f1cd4b50 | (Timo Paulssen)++ | 2 files
Emit Deopt Annotations For smrt_strify/smrt_numify

These have to be present so that these ops can be turned into a method call that's supposed to be inlinable.
MoarVM/inline_smart_coerce_methodcalls: 6d5a49b393 | (Timo Paulssen)++ | src/spesh/optimize.c
Turn smrt_strify/_intify Into Method Calls

and potentially inline them immediately.
timotimo this will of course have to be changed a little when smrt_intify lands in master
okay, time to get some sleep!
timotimo .tell MasterDuke if you haven't seen it in the backlog yet, my new branch has just appeared, "inline_smart_coerce_methodcalls"; after smrt_intify lands (along with the rest of nqp-int) i'll make the necessary changes unless you want to do it yourself 03:17
yoleaux timotimo: I'll pass your message to MasterDuke.
MasterDuke timotimo++, passes spectest 03:24
yoleaux 03:17Z <timotimo> MasterDuke: if you haven't seen it in the backlog yet, my new branch has just appeared, "inline_smart_coerce_methodcalls"; after smrt_intify lands (along with the rest of nqp-int) i'll make the necessary changes unless you want to do it yourself
MasterDuke nice. i'll work on cleaning up my branches and should be PRing them in the next couple days 03:25
Geth MoarVM/jit-2op-form: dff6109658 | (Bart Wiegmans)++ | 4 files
[JIT] Enfore input/output registers better

Also do it for unary input/output operators (NOT). Remove register-moving code in most tiles.
12:28
brrt o 12:32
yoleaux 06:55Z <AlexDaniel> brrt: some cool hardcore ideas from you? :) github.com/perl-gsoc-2019/ideas
brrt AlexDaniel: I've got a few ideas, for sure :-)
.ask AlexDaniel how can I submit an idea?
yoleaux brrt: I'll pass your message to AlexDaniel.
patrickb brrt: Just add a pull request to that repo 12:35
There is a template file in there. 12:36
MasterDuke ugh, my branches pass all tests and spectests, but they are not the cleanest series of commits. not looking forward to trying to tease some semblance of order out of them 13:25
brrt MasterDuke: just put up a PR and we'll bully you into conformity :-P 13:29
MasterDuke heh. i'm going to do a little cleanup, but not gonna be exhaustive about it 13:43
Geth MoarVM/jit-expr-float: 5 commits pushed by (Bart Wiegmans)++ 15:06
MoarVM/jit-expr-float: 14 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/1...22a8069b64
brrt rebase of jit-expr-float on top of jit-2op 15:07
the tl;dr - now the register allocator handles the conversion to two-opernds form, and tiles can be a bit dumber
timotimo wdtz.org/files/oopsla18-allmux-dietz.pdf 17:05
o_O
"statically link together all programs from a given package to make it a lot smaller in total, and quite a bit faster, too" 17:06
BTW is there a reliable API for figuring out what actual address a dynamically-resolved function will call so that our jit could skip one layer of indirection?
As 17:18
another example, for a set of 10 applications using Qt, the disk size of the multiplexed version is 17:19
17% smaller than shared and 66% smaller than static, in aggregate, and the memory usage (when all
10 run concurrently) is 40% less than shared and 63% less than static.
timotimo hum. the JIT is in the same shared object as most of the functions it likes to put into code as calls, does that mean that maybe it already gets a "proper" address for the function rather than a forwarder stub? 19:50
timotimo at least op_to_func gives a function pointer that looks very much like the final function itself 19:56
timotimo no opportunity for cheap speedups here :( 20:07
brrt timotimo: I'm not entirely sure what your question is 20:25
our state of the art is that we load the in-memory function pointer into the '.data' section of the code 20:26
timotimo right, this is all just about "is the function pointer that we get from our C code direct or indirect"
brrt hehe, well, I don't exactly know that, tbh 20:33
you can't really be sure
libraries can do what they want
timotimo well, i grabbed the pointer in gdb and disassembled it and at least in that case it looked direct 20:34
brrt hmm. yes, they tend to 20:36
timotimo OK, so what other ops sometimes turn into a method call that we could theoretically spesh + inline 20:41
i believe decont does this for proxies
brrt oh, you're making invokish things actually invoke? 20:44
that's a good idea
timotimo yeah 20:46
hopefully :)
got any suggestion where i should look next? 20:51
brrt anything marked invokish in oplist, I'd guess 20:53
exit 20:54
timotimo oh, hum. 21:10
i think i got the precedence of & and && right when i thought i had it wrong
value & testbit && othercondition seems to actually correctly turn into (value & testbit) && othercondition 21:11
timotimo jnthn: do you think it's a good time to look into inlining FETCH and STORE for proxies? 21:23
jnthn timotimo: Sure, why not... :) 21:24
timotimo .o( am i going to regret this ... )
jnthn Well, with the "but maybe merge after release" thing :)
9 blockers in Rakudo is...already a lot to deal with
timotimo aye 21:25
i'm not sure i can help with any of them, though if you think one seems up my alley, feel free to ping
i'm just experiencing a random spurt of spesh-focussed productivity
do you have a clue if it's wrong that i had to give smrt_*ify a :deoptonepoint and a :deoptallpoint so that i get those annotations in the spesh graph? 21:26
it seems like :invokish and/or :maycausedeopt should already cause them to appear
but it seemed like they didn't
AFK for a bit first
jnthn There's no implicit flags
You'd have to spell those out
Though I think you only need a deoptallpoint 21:27
timotimo OK! 22:22
hum. with code_pair, we'll be grabbing the code object at run time, not yet know it at spesh time ... 22:38
perhaps we could actually log the invoked thing at the address of the op, even though it's not an actual invoke op 22:39
otherwise it feels like a long way until inlining of store/fetch works :) 22:40
jnthn timotimo: Hm, ain't the code objects hung off the stable pointer? 23:06
Under invocation_spec
timotimo oh, do we actually have an STable per pair of fetch/store? 23:12
timotimo you're right, it does hang off of the STable 23:13
that makes it easier for sure
jnthn So if the type is known...:)
timotimo does that mean we generate a crapton of Proxy objects that all close over something else, that spesh would get kind of confused?
i might be confused. 23:14
jnthn Yeah, I guess there's then another level of call 23:20
So an improvement is possible now, but not a full inlining of the two levels 23:21
timotimo oh, so it goes off to grab the actual proxy object itself which then has the closure
the only way i was able to get spesh on decont able to stumble into the code path for code_pair was to actually put a literal nqp::decont into the source of my test code 23:34
i'll just put an MVM_oops in and see if many test cases die ... 23:40