|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:31
stmuk_ joined
00:33
stmuk left
02:08
stmuk joined
02:10
stmuk_ left
03:46
stmuk_ joined
03:47
stmuk left
05:49
lizmat left
06:15
lizmat joined
06:57
domidumont joined
07:02
domidumont left
07:03
domidumont joined
07:16
lizmat left
07:27
robertle joined
07:38
lizmat joined
08:09
mst left,
mst joined,
ChanServ sets mode: +o mst
08:54
domidumont left
|
|||
| Geth | MoarVM: a24033eb0f | (Samantha McVey)++ | 3 files Make coerce_is/us 2x faster Instead of using snprintf, we use some dedicated code to convert the 64bit int/uint to a string. In addition, avoid decoding into a MVMString and simply copy the buffer over directly (do this for coerce_ns as well). |
09:34 | |
|
09:52
travis-ci joined
|
|||
| travis-ci | MoarVM build failed. Samantha McVey 'Make coerce_is/us 2x faster | 09:52 | |
| travis-ci.org/MoarVM/MoarVM/builds/401399471 github.com/MoarVM/MoarVM/compare/4...4033eb0f39 | |||
|
09:52
travis-ci left
|
|||
| MasterDuke | is it ok/safe to rename an op in src/core/oplist? or does the old one have to be deprecated and a new one with the new name created? | 12:26 | |
| jnthn | So long as you leave at at the same place in oplist, the op number stays the same | 12:28 | |
| So there's no risk of breaking the stage0 bootstrap | 12:29 | ||
| MasterDuke | cool, thanks | 12:32 | |
| oh, and then i can just change the name in NQP? without having to re-bootstrap? | 12:33 | ||
| jnthn | Yes | 12:34 | |
| MasterDuke wonders why i didn't just start the rename in MoarVM in the first place | 12:35 | ||
| jnthn | :) | ||
| MasterDuke | hm. is an expr template useful if the op isn't also jitted in src/jit/graph.c? | 12:43 | |
|
12:48
domidumont joined
14:02
lizmat_ joined
14:03
lizmat left
14:09
lizmat_ is now known as lizmat
14:38
zakharyas joined
|
|||
| timotimo | yes | 14:47 | |
| MasterDuke: it is | |||
| but only if it tends to follow ops that are also exprjitted | 14:48 | ||
| since the exprjit only kicks in at the start of BBs and aborts on the first non-exprjit-supported op | |||
| MasterDuke | ah, good to know, thanks | 14:52 | |
|
15:02
Kaiepi left
15:03
Kaiepi joined
15:08
lizmat_ joined
15:09
lizmat left
15:10
lizmat_ left
15:35
zakharyas left,
zakharyas joined
15:39
zakharyas left
15:41
zakharyas joined
16:00
Kaiepi left
16:01
Kaiepi joined
|
|||
| Geth | MoarVM: MasterDuke17++ created pull request #899: Rename (and JIT) getstrfromname |
16:28 | |
|
17:07
zakharyas left
17:33
stmuk joined
17:35
stmuk_ left
17:44
zakharyas joined
17:47
MasterDuke left
17:48
MasterDuke joined
18:11
domidumont left
18:50
zakharyas left
19:13
Kaiepi left
|
|||
| Geth | MoarVM: jstuder-gh++ created pull request #900: Add more exprjit templates (07/08/18) |
19:13 | |
|
19:14
Kaiepi joined
19:31
zakharyas joined
19:48
Kaiepi left
19:51
Kaiepi joined
20:01
lizmat joined
20:28
zakharyas left
20:43
robertle is now known as test234,
test234 is now known as robertle
21:12
robertle left
21:57
MasterDuke left
|
|||
| jnthn | Urgh. Currently discovering that we've played a bit fast and loose in various places with the SSA form in spesh, and now I'm trying to get us actual du-chains, that bites. | 22:04 | |
| But, there's good news. I've written the first third of a sanity checker. | 22:05 | ||
| That already finds various violations for me to work through. | |||
| But when this is done, we'll know that our usage is spot on. I'm betting there's a few places that we don't properly decrement usage that we should, so we might even get some perf wins out of this. At the very least we'll get correctness wins. | 22:06 | ||
| timotimo | awesome | 22:09 | |
| Geth | MoarVM/du-chains-and-opts: 202c0ba8fb | (Jonathan Worthington)++ | src/spesh/optimize.c Correct a wrong instruction in usage delete |
||
| MoarVM/du-chains-and-opts: ae5654d1e9 | (Jonathan Worthington)++ | 3 files First steps to a DU-chain checker This just checks the D part of things is OK - that is, the ->writer in the facts actually matches the instruction that really writes the register. Already catches some problems, which will be corrected in upcoming commits. |
|||
| jnthn | And the reason I'm doing du-chains is because they'll let us cheaply fine the answer to "is this box instruction used by an unbox" and "is this native ref taking instruction used by a decont" | 22:12 | |
| *find | |||
| timotimo | very good | ||
| how much easier is it compared to following the writer chain from the facts? | |||
| jnthn | Well, that tells you it backwards, I guess, but knowing it forwards seems better | 22:13 | |
| timotimo | that's fair | ||
| jnthn | Since it's then possible to tell if all the usages are unboxing | ||
| Or just some of them | |||
| timotimo | we'll still have to do safety checking that registers aren't clobbered, or will we always introduce extra registers in that case? | 22:14 | |
| jnthn | Planning to introduce temps, and then when that's working optimize that away for the non-clobbering case. | 22:15 | |
| timotimo | OK | ||
| jnthn | I figure extra temps are a good bit cheaper than an extra allocation + GC of it :) | 22:16 | |
| And certainly cheaper than a native ref and decont of it | |||
| timotimo | hm, i forgot what the bucket size difference is in the fsa, but will one more register always move us to the next bigger bin? | 22:17 | |
| jnthn | Not always | ||
| Uff, current problem is | |||
| sp_getspeshslot r43(14), sslot(20) | |||
| then after it | |||
| sp_getspeshslot r43(14), sslot(20) | |||
| timotimo | yeah, i've seen that before | ||
| jnthn | oops, that was the same paste | ||
| timotimo | probably a misguided optimization i made at some point | ||
| jnthn | sp_getspeshslot r43(14), sslot(21) | ||
| That's the one I wanted | 22:18 | ||
| timotimo | yeah, same register and version as the target | ||
| for the target* | |||
| jnthn | Right, that's a violation of SSA form | ||
| timotimo | i'd assume it comes from the method lookup optimization | 22:20 | |
| Geth | MoarVM/du-chains-and-opts: ca9aa46380 | (Jonathan Worthington)++ | src/spesh/inline.c Missing writer setting in inline handling |
22:22 | |
| MoarVM/du-chains-and-opts: 48fd24cadc | (Jonathan Worthington)++ | src/spesh/optimize.c Missing writer setting in resolvecode insertion |
|||
| MoarVM/du-chains-and-opts: 4d1e27d238 | (Jonathan Worthington)++ | src/spesh/optimize.c Correct writer when optimizing object conditional |
|||
| jnthn | No, method lookup seems OK, it just turns findmeth into a getspeshslot | 22:29 | |
| I'm guessing the other one comes from an invocation optimization | |||
| timotimo | OK | 22:30 | |
| jnthn | Yeah, it's optimize_call that inserts the naugty one | 22:31 | |
|
22:38
committable6 joined,
reportable6 joined
|
|||
| Geth | MoarVM/du-chains-and-opts: 11b44e7964 | (Jonathan Worthington)++ | src/spesh/optimize.c Stop cheating on SSA form in optimize_call Use a temporary register for now, which we already have code in place to handle anyway becuase it's exactly what we do for the guard path. Plus this should mean we can delete an unrequired earlier instruction that's also reading from a spesh slot, to save some cycles. Most importantly, however, it means we don't violate SSA form. |
22:49 | |
| jnthn | Next: | ||
| hllboxtype_i r5(8) | |||
| box_i r5(8), r18(1), r5(8) | |||
| grmbl :) | |||
| But that can be tomorrow's fun | |||
| timotimo | that could be from rakudo's ops.c | ||
|
22:49
lizmat left
|
|||
| timotimo | maybe i'll take a look at it righ tnow | 22:50 | |
| huh, no spesh function for p6box_i it looks like | 22:51 | ||
| ah, might be args.c | 22:52 | ||
| jnthn | Entirely possible | 22:54 | |
| timotimo | is this from named arguments? | ||
| samcv | jnthn: well i got that hash script for nqp 30% faster, reduced a fair amount of time in gc_mark by making a more optimized HASH_ITER macro | ||
| timotimo | the pos_box function uses temp registers at first glance, but the one for slurpy optimization doesn't seem to | ||
| jnthn | Very possible, because it's at the start of an inline | ||
| timotimo | no, that also has temps | ||
| jnthn | hm, not very very start, mind | 22:55 | |
| timotimo | what code are you getting this for? i'd like to reproduce it | ||
| jnthn | make clean in NQP, then `make` :) | 22:56 | |
| It explodes in the very first file | |||
| timotimo | excellent | ||
| jnthn | It produces something like this: | ||
| MoarVM oops: Malformed DU chain: writer hllboxtype_i of 5(8) in BB 26 is incorrect | |||
| Which lets you quite easily locate it :) | |||
| timotimo | do you have local modifications to turn that on? | 22:57 | |
| jnthn | No, I comitted it for now until I get the thing working :) | ||
| timotimo | it doesn't explode on my end :| | ||
| ... | |||
| i forgot to check out the branch | |||
| jnthn | ah :) | ||
| timotimo | return_to_box from inline.c could be the culprit | 22:59 | |
| aha, it turns the return instruction into the hllboxtype_i instruction and *then* inserts the box_i | 23:00 | ||
|
23:01
lizmat joined
|
|||
| Geth | MoarVM: samcv++ created pull request #901: Make a faster HASH_ITER macro and make other hash optimizations |
23:01 | |
| timotimo | it appears i have to register that i set it as the writer for an added instruction | 23:03 | |
| found it | 23:04 | ||
| it gets to a different frame now, is_scope | 23:05 | ||
| elems r17(0), r6(3) | |||
| coerce_in r7(1), r17(0) | |||
| that's probably a simple fix of just putting the writer into the facts when that opt happens | |||
|
23:05
lizmat left
|
|||
| jnthn | Yes, we've been failing to set ->writer in various places too | 23:07 | |
| Going to rest, 'night o/ | 23:11 | ||
| timotimo | gnite jnthn | 23:14 | |