github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt \o 07:35
brrt .ask timotimo if the work on the spesh 'comments' ever got anywhere 07:40
yoleaux brrt: I'll pass your message to timotimo.
brrt oh, that is in postrelease-opts, I see now 07:48
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
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
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
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
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
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
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
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
jnthn tests well 10:03
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
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
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
[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
[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
nine Aaaaand spectest passes :) 14:01
lizmat whee! 14:21
[Coke] ten! 14:24
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
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
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
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
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?

Powered by Cro and the Raku® Programming Language.

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

Thank you!