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
01:17 MasterDuke left
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
02:05 MasterDuke joined, MasterDuke left, MasterDuke joined
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
02:13 dogbert17 left
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++
03:10 MasterDuke_ joined
MasterDuke_ ugh, my laptop battery is just not working well at all 03:10
timotimo d'oh
03:10 MasterDuke left
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!
03:15 MasterDuke_ left
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.
03:19 robertle left, robertle joined 03:24 MasterDuke joined, MasterDuke left, MasterDuke joined
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
03:32 AlexDani` joined 03:36 AlexDani` left, AlexDani` joined, AlexDaniel left, AlexDani` is now known as AlexDaniel 03:49 robertle left, robertle joined 03:51 martin__ joined 03:55 ufobat_ left 04:01 MasterDuke left 04:02 MasterDuke joined 04:04 MasterDuke left, MasterDuke joined 06:49 domidumont joined 07:20 domidumont left 07:50 patrickb joined 07:51 martin__ is now known as ufobat 08:10 domidumont joined 08:25 zakharyas joined 09:16 robertle left 09:17 robertle joined 10:59 dogbert2_ joined
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
12:31 brrt joined
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.
12:33 lucasb joined
patrickb brrt: Just add a pull request to that repo 12:35
There is a template file in there. 12:36
12:41 zakharyas left 12:53 jpf1 left, jpf1 joined 13:20 dogbert2_ left 13:23 patrickb left
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
13:56 zakharyas joined
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
15:14 dalek left 15:15 dalek joined, brrt left 15:18 robertle left, robertle joined 15:33 lucasb left 15:34 [Coke] left 15:41 brrt joined 16:22 domidumont left 16:45 brrt left 17:03 lizmat left
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.
17:28 patrickb joined 18:24 dogbert17 joined 18:25 patrickb left
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
19:55 robertle left, robertle joined 19:56 robertle left
timotimo at least op_to_func gives a function pointer that looks very much like the final function itself 19:56
19:56 robertle joined 20:03 robertle left 20:05 lizmat joined
timotimo no opportunity for cheap speedups here :( 20:07
20:10 robertle joined 20:24 brrt joined
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"
20:29 AlexDani` joined 20:31 AlexDaniel left
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
20:40 AlexDani` is now known as AlexDaniel
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
20:43 zakharyas left
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
20:54 brrt left
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
21:19 robertle left
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
21:40 Kaiepi left 21:46 Kaiepi joined 21:59 MasterDuke left
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
23:12 MasterDuke joined
timotimo oh, do we actually have an STable per pair of fetch/store? 23:12
23:12 MasterDuke left, MasterDuke joined
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!