github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:26 lucebac0 joined, lucebac0 left 00:42 ggoebel_ left 00:48 rootnode joined, rootnode left 01:09 Kaypie left 01:22 lizmat left 01:33 zakharyas joined 01:34 p6bannerbot sets mode: +v zakharyas 01:38 ggoebel_ joined, p6bannerbot sets mode: +v ggoebel_ 01:57 onnex2 joined, onnex2 left 02:12 ZzZombo left 02:28 Seju joined, Seju left 02:47 samulihs8 joined, samulihs8 left 02:53 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 03:02 tcunha22 joined, tcunha22 left 03:29 MasterDuke left 04:22 ggoebel_ left 05:07 HisShadow_3 joined, HisShadow_3 left 06:19 patrickb joined, p6bannerbot sets mode: +v patrickb 06:27 robertle joined 06:28 p6bannerbot sets mode: +v robertle 06:33 domidumont joined 06:34 p6bannerbot sets mode: +v domidumont 06:40 ggoebel left 06:41 robertle left 06:53 ggoebel joined 06:54 p6bannerbot sets mode: +v ggoebel 07:27 sgallagh15 joined, sgallagh15 left 07:33 brrt joined 07:34 p6bannerbot sets mode: +v brrt
brrt \o 07:35
07:39 ZzZombo_ joined, p6bannerbot sets mode: +v ZzZombo_
brrt .ask timotimo if the work on the spesh 'comments' ever got anywhere 07:40
yoleaux brrt: I'll pass your message to timotimo.
07:41 ZzZombo left, ZzZombo__ joined, ZzZombo__ is now known as ZzZombo, p6bannerbot sets mode: +v ZzZombo 07:44 ZzZombo_ left
brrt oh, that is in postrelease-opts, I see now 07:48
07:53 lizmat joined 07:54 dogbert17 left, p6bannerbot sets mode: +v lizmat
masak is there a good design document on 6model floating around somewhere? or a set of blog posts? 07:57
suddenly I have a great thirst for knowing the intricate details about vtables and reprs
samcv masak: there's stuff in docs/ there might be something useful there
maybe some blogs but i don't know any on the top of my head
masak samcv: ta, I'll start there
nine Note to self: when you look at a hexdump of some MoarVM bytecode and think "ah, of course, it's using the wrong opcode there!" you should probably take a bit of a break... 08:02
masak ah, there's a docs/6model/ directory in the perl6/nqp repo. that looks like a good start. 08:04
jnthn masak: Also read 6model.h, which has the key data structures 08:14
08:23 popey19 joined, popey19 left
nine All tests successful. 08:25
masak jnthn: ah, d'oh, yes -- I will.
nine NQP's test suite passes with my MoarVM::BytecodeWriter plugged into assemble_and_load :)
masak jnthn: ooc, and since you probably know offhand -- has 6model.h gone through any significant change since you designed 6model back in 201*mumble*? 08:26
samcv jnthn: also. so i am now doing what perl 5 does and utf16be and utf16le i pass through a BOM (don't expect one). and on utf16 it removes the BOM if it exists when reading and does encoding detection 08:27
but if we *write* to utf16 then we don't get any BOM. but then again writing to a file never actually worked. but also they both use .encode
so can we change it so that .encode adds a BOM? or what. or only writing to a file(though that would be more work but maybe i could do it?) 08:28
but i don't like how we can write a file on one perl6 machine and then on another of a different endianess it will read wrong if you try and read it...
jnthn nine: omg...wow! 08:35
masak: Not really; the most significant addition was the parametric extensions. 08:36
samcv: I think we can change it to add the BOM
samcv: There's slight back-compat concerns but given we were missing the streaming decoder for it even, well, I think usage was probably quite low :) 08:37
What does "pass through a BOM" mean exactly?
lizmat jnthn: I think the main need was to be able to read utf16, specifically for Text::CSV like applications 08:41
08:42 brrt left
jnthn Righty, what was I going to work on next... 08:42
ah, the thingy dogbert found... 08:43
uff, that's a big frame... 08:45
samcv jnthn: well if it has a BOM and you read using utf16le you get zero width no-break space. which is what the standard says and what perl 5 does 08:51
though iconv will drop the BOM assuming it's a BOM
jnthn Ah, I see
samcv also should "foo".encode have a BOM? i want to say no
08:51 dogbert2 joined
jnthn What's the argument for it not having one? 08:52
samcv concatenating strings
"foo".encode you might not want to write it directly to a file
08:52 p6bannerbot sets mode: +v dogbert2
samcv since .encode isn't working on a file just a string 08:53
dogbert2 o/
jnthn What will .decode do?
samcv well probably what it does now. but i guess my point is that .encode is an isolated fragment, while if we write to a file we know that's the start 08:54
i mean if you did $fh.write: "hello".encode('utf16') it's gonna have a bom. but i mean we *could* do that. and just have it documented you should probably do 'utf16le' or utf16be if you're doing fragments 08:55
jnthn Hmm...yeah, that'll be a bit of a trap
08:56 brrt joined, p6bannerbot sets mode: +v brrt
lizmat
.oO( claymore )
09:02
dogbert2 jnthn: if you get bored with the big frame I can offer a SEGV instead :)
jnthn I think the problem with the big frame is that it has multiple `return` instructions and we mis-handle that 09:10
(Produce invalid SSA form) 09:11
09:12 Spritz3 joined, Spritz3 left
jnthn Since we just rewrite the return instruction into a set to the invoke register, but...if there's two such rewrites both will write the same location 09:13
Well, same version
And then the DU chain checker is rightly upset
The only place we code-gen anything of this form is in regexes 09:14
(at the moment)
dogbert2 is it fixable? 09:19
jnthn Well, the super-easy fix is just to refuse to inline such things, which is easy 09:20
but...means we can't inline such things :)
dogbert2 which would be a bit sad :)
jnthn A bit, though it's not super common (otherwise we'd know about it :))
Or at least, know about it a lot more :) 09:21
brrt nine++ cool!
jnthn The proper way to do it is to generate new versions of the target and then insert a PHI
dogbert2 are you leaning towards the latter approach 09:22
jnthn Yeah, think so. It'll only come back as a task to fix a missed opportunity to inline in the future :) 09:23
The next question after that is how to factor it.
I guess a PHI is free (goes away at code-gen time) so we could just always insert it 09:26
Which is cleaner than trying to keep state around for if we already rewrite a return and patch things up afterwards 09:27
dogbert2 it will be interesting to see how postrelease-opts affects [Tux] csv benchmark 09:47
09:55 ZzZombo left
jnthn tests the fix 09:57
It's kinda more elegant this way, because before if there was more than one return then we just didn't try and propagate facts out of the inlinee, whereas now we just let the normal phi facts merge take care of it 10:00
10:02 b-jazz4 joined, b-jazz4 left
jnthn tests well 10:03
10:09 domidumont left
timotimo we must not forget that you can also write to/open files at non-0 offsets 10:09
yoleaux 07:40Z <brrt> timotimo: if the work on the spesh 'comments' ever got anywhere
Geth MoarVM/postrelease-opts: 8aaf696a32 | (Jonathan Worthington)++ | src/spesh/inline.c
Fix SSA handling of inlinees with multiple return

Generate new SSA versions for each return point, and then merge then at a PHI placed after the inlinee. This potentially offers better facts for optimization in such cases, since before we propagated no facts out of the routine if there was multiple object returns, whereas now we let PHI fact merging identify commonalities. Further, we now propagate facts from non-object return values too.
jnthn dogbert2: And you had a SEGV? 10:11
10:16 brrt left 10:21 brrt joined, p6bannerbot sets mode: +v brrt
brrt so. do we think we can merge fork-safety prior to the release, or shall we do it after? 10:32
lizmat I would suggest after 10:35
AlexDaniel just did a toast run 10:36
AlexDaniel` yeah, after 10:37
nine The spectest failures I get seem to be about bytecode validation errors which depend solely on frame size. That's intriguing 10:38
brrt fine, after it is 10:42
nine: where (if anywhere) are you hosting your work? I'd like to take a peek :-) 10:43
Geth MoarVM/nqp-mbc: e5fd915624 | (Stefan Seifert)++ | 9 files
Add the buffertocu op
MoarVM/nqp-mbc: b50afaf7ae | (Stefan Seifert)++ | 6 files
First stab at a writedouble op
MoarVM/nqp-mbc: 7b5da981f0 | (Stefan Seifert)++ | tools/update_ops.p6
Fix MVM_operand_type_mask in lib/MAST

The old mask was not extended when unsigned types were added.
nine brrt: there you go :) same branch in nqp
10:45 zakharyas left
brrt cool :-) 10:45
thanks 10:46
dogbert2 jnthn: yes I have a SEGV 10:50
jnthn: try this gist.github.com/dogbert17/23b5e847...c582760963 10:51
jnthn oh, that one 10:52
Yeah, I'll leave that for now...it's not new, and it's quite a time sink..
dogbert2 aha
in that case I'm not sure that I have anything else 10:53
heh, suddenly I'm unable to repro the SEGV 10:55
jnthn You saw it after yesterday's GC fix, I presume? 10:56
dogbert2 yes 10:57
but not after your SSA fix
perhaps I'm doing something wrong :) 10:58
dogbert2 reverts jnthn's latest fix and tries again ... 10:59
nah, can't reproduce it atm :( 11:19
11:27 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 11:41 Kaiepi joined 11:42 p6bannerbot sets mode: +v Kaiepi 11:51 brrt left 12:15 ggoebel_ joined 12:16 p6bannerbot sets mode: +v ggoebel_ 12:48 brrt joined, p6bannerbot sets mode: +v brrt
[Coke] What's the plan on merge timelines? 13:18
jnthn 1) Release. 2) Merge all the things. 13:19
:P
nwc10 Octopus merge! 13:21
nine The bytecode validation errors seem to occur when there are more than 4685 locals in a frame 13:23
jnthn m: say 4685.base(16) 13:24
camelia 124D
13:30 patrickb left
[Coke] cool. 13:33
nine Nah, looks to be more about bytecode size. When I turn the 4685 variables into int typed ones, the bytecode becomes smaller and I can raise the limit. The bytecode size limit is eerily close to 2^16 but it seems to be slightly above that. 13:50
LOL and there it is: 'write_uint32_at', method (uint32 $i, uint16 $pos) 13:52
13:57 andries5 joined, andries5 left
nine Aaaaand spectest passes :) 14:01
lizmat whee! 14:21
[Coke] ten! 14:24
14:35 ggoebel_ left
japhb Awesome, nine++! 14:49
Actually, very happy to see *three* very cool branches ready to go in 14:50
brrt unfortunately all of them add new ops, so merge conflicts abound 14:58
we'll manage though :-)
jnthn It's easy, just run the update_ops.p6 :) 15:15
15:16 ggoebel_ joined 15:17 p6bannerbot sets mode: +v ggoebel_ 15:24 indutny8 joined, indutny8 left 15:49 fgau25 joined, fgau25 left 15:56 brrt left 15:57 lizmat left, domidumont joined 15:58 p6bannerbot sets mode: +v domidumont 16:15 AlexDaniel left 16:19 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel 17:01 avar left 17:03 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar
japhb jnthn: Does that deal with merge conflicts automatically? 17:10
[Coke] more "ignore them and just redo that file." 17:16
diakopter obviously doesn't work if any branch re-bootstraps 17:19
17:27 brrt joined 17:28 p6bannerbot sets mode: +v brrt 17:31 W6MCN8 joined, W6MCN8 left 17:35 bisectable6 left, bisectable6 joined 17:36 p6bannerbot sets mode: +v bisectable6
jnthn japhb: Well, it means that if you resolve conflicts in oplist (if any) then you just regenerate the rest. It doesn't do any magic like `git add` of the things it generates, though. 17:36
nine The final missing bit for using my bytecode writer in assemble_to_file is writing the serialized data. There doesn't seem to be a way to access it from NQP however 17:42
17:45 bisectable6 left, bisectable6 joined 17:46 p6bannerbot sets mode: +v bisectable6 17:50 lizmat joined 17:51 p6bannerbot sets mode: +v lizmat 17:57 brrt left 18:03 brrt joined 18:04 p6bannerbot sets mode: +v brrt
nine Or maybe there is... nqp::serialize seems to return a "string" with the serialized data 18:12
But not "when we're in the compiler pipeline". I wonder when it would be called outside the compiler? 18:14
18:16 avar left 18:22 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 19:07 domidumont left 19:13 xificurC joined, xificurC left 19:16 brrt left 19:33 kierank20 joined 19:34 kierank20 left 19:59 tomreyn17 joined 20:00 tomreyn17 left 20:34 Milt`n0 joined, Milt`n0 left 21:19 ggoebel_ left 21:40 Ragnor18 joined, Ragnor18 left
timotimo you know, we could have an sp_index for when the needle is spesh-time-known and have a little cache for the advance/skip/whatever table 22:02
though i think if the needle is short, like for example \", it won't be big at all?
22:22 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 23:56 ggoebel_ joined 23:57 p6bannerbot sets mode: +v ggoebel_