SmokeMachine github.com/MoarVM/dyncall/blob/master/configure does that mean that moar can be configured to be compiled for iOS? 00:32
02:06 pyrimidi_ joined 03:13 TimToady_ joined 04:30 pyrimidine joined 06:07 pyrimidine joined 06:57 ilbot3 joined 06:58 camelia joined 08:06 domidumont joined 08:11 domidumont joined 08:40 ilbot3 joined 11:42 FROGGS joined 11:55 Ven joined 13:23 brrt joined
brrt good * #moarvm 13:23
merry boxing day and stuff
i realised today that there are only a few barriers to integrating the new linear scan allocator, and i'm ambitious abotu removing them 13:24
lizmat brrt++ 13:25
brrt do you want an explanation of those barriers? :-) 13:28
lizmat please do 13:29
.oO( let me be your rubber duck )
brrt alright. what i've done is I've encoded the fact that certain 'base' values (thread context, MoarVM register buffer) are always present in certain non-volatile registers 13:30
well, i've encoded the fact that these 'tiles' map to those registers; i'm now recording the fact that these are non-volatile 13:31
so the next bit to do is to use that encoding to detect this case (non-volatile register, fixed register, empty emit function) to automatically assign the correct value to the live range that springs from those tiles 13:32
which is currently hardcoded by looking at the 'op'
having done that, i need to replicate that knowledge in the linear scan allocator. I then want to extract the logic that does register assignment, and replace the call to the old register allocator with a call to the new one 13:33
having done that, i'll need to spend some time in a debugger ironing things out
when that works for the current set of things, i can add the spillage logic 13:34
and when that works i can attempt splitting, which is a kind of special case 13:35
lizmat listens
brrt when that works, i can start implementing ARGLIST handling. that will need some care because ARGLIST can 'force' a register requirement upstream
not a problem yet, because i have very few tiles that have real requirements with regards to registers. but it will be because there are plenty of x86 instructions which are limited in that way 13:36
actually, doing ARGLIST first is probably a better idea
lizmat fwiw, I always try to do the most complicated case first: simpler cases will just follow out of that 13:39
brrt hmm
let me think about that for a bit
lizmat although the most complicated case may have scaffolding in place, to make things work
brrt the other hand is that if you do simpler bits first, you will have some of that scaffolding to make the complex case work 13:40
also, a particular difficulty in JIT/VM development is finding cases in which combinations of features run
lizmat well, yes, that's the other way: unless you need to redesign to be able to support the complex case
brrt yeah....
that's basically the situation i've had with this :-) 13:41
and yet, there's no way of finding out, really, until you do it
lizmat yes, we like to torment developers :-) 13:42
brrt :-) 13:43
otherwise, where is the challenge
in hindsight, the greatest confusion i've had is about the definition of the concept 'live range' 13:45
i mean, you hear 'range' so you think 'start and endpoint'
turns out, that's not sufficient at all
anyway, that's the topic of a blog-post-in-the-works
lizmat looking forward to that! 13:51
brrt i'll do my best :-) 13:53
jnthn brrt++ # JIT-hacking even during holidays :) 13:56
yoleaux2 23 Dec 2016 12:10Z <lizmat> jnthn: as a datapoint: t/spec/S11-modules/nested.t very occasionally flaps (no tests seen) for me (like less then 1/20)
23 Dec 2016 16:07Z <nwc10> jnthn: new ASAN barfage from spectest6: paste.scsys.co.uk/540350
24 Dec 2016 02:14Z <samcv> jnthn: when I try and generate with roast/S15-nfg/test-gen.p6 only one of the tests (mass-chars.t) actually seem to generate more than 2 passing tests, the rest all fail with either UCD 8.0 or UCD 9.0
25 Dec 2016 18:00Z <notviki> jnthn: what can I read to understand how to fix Optimizer bugs? Books? Papers? Docs? Anything?
25 Dec 2016 22:05Z <notviki> jnthn: can you review github.com/perl6/roast/commit/3baa...d1f30dda15 The test file referenced in the commit message is github.com/perl6/roast/blob/master...reakTest.t
jnthn omg /o\
brrt hahaha 13:58
jnthn Evidently others did not decide to take a couple of days away from the keyboard while I was doing so. :-)
brrt hmm, having a clear 'that's odd' moment here.. 14:02
aha 14:13
(i'm wondering if lldb and me are ever going to be buddies)
jnthn I've barely used lldb
brrt it's like a not-as-friendly version of gdb 14:14
jnthn Quite comfortable in GDB these days
brrt you can install gdb on OS X, but it's a pain with certifcations 14:17
dalek arVM/even-moar-jit: 243082f | brrt++ | src/jit/ (3 files):
Mark and detect non-volatile required registers

Some 'definition' tiles (like TC and CU) direct to non-volatile registers and so need to be handled specially by the register allocator. This used to be detected by looking at the opcodes of those tiles, but now this looks at the required register, which is more flexible and more portable.
This needs to be replicated in some way for the linear scan allocator.		 14:23
brrt (linear_scan.c does not compile, as could be expected :-)) 14:45
15:52 brrt joined
dalek arVM/even-moar-jit: 8242f97 | brrt++ | src/jit/ (2 files):
Make linear_scan.c valid C

Which is at least a precondition to integration as the default register allocator.		 16:01
brrt now i still have to add the logic to deal with the non-volatile registers in the linear scan allocator. but i can take at least look at the original implementation 16:11
now that i think of it, arglist is also a definition 16:23
16:56 brrt joined 17:23 pyrimidi_ joined
jnthn .tell samcv About test-gen.p6 it was iirc written before some fairly major changes (including the Great List Refactor), and it's entirely possible the generator script is busted as a result. It was run against UCD 8.0 originally, so certainly produced passing tests against that. So I suggest "use UCD 8.0 and fix it to prdouce the same output first" would be one way to go. 18:20
yoleaux2 jnthn: I'll pass your message to samcv.
jnthn .tell samcv Will try and catch up with your MoarVM PR and other Unicode bits that may want my input soon too; getting some much-needed rest these last days. :-) 18:21
yoleaux2 jnthn: I'll pass your message to samcv.
jnthn .tell notviki Depends which optimizer you're talking about. If the Perl6::Optimizer than that is really nothing more than a tree re-writer - it walks the QAST tree recursively, remembers various things, and uses them to guide transformations. If spesh in MoarVM, some reading on basic blocks and SSA form (what it is more than how to compute it) will stand you in a good place to read graph.h - the data structure that all spesh hangs off. 18:24
yoleaux2 jnthn: I'll pass your message to notviki.
jnthn That digs me out of at least a little of the backlog of questions. :-) 18:25
notviki Thanks. 18:26
yoleaux2 18:24Z <jnthn> notviki: Depends which optimizer you're talking about. If the Perl6::Optimizer than that is really nothing more than a tree re-writer - it walks the QAST tree recursively, remembers various things, and uses them to guide transformations. If spesh in MoarVM, some reading on basic blocks and SSA form (what it is more than how to compute it) will stand you in a good place to read graph.h - the data structure that all spesh hangs off.
jnthn notviki: I'm between the keyboard and the stove, but anything in particular I can answer about them? :) 18:33
notviki Not really. I guess I need to learn more about QAST. It's just yesterday it's been like 4th or 5th time where I found the place where the bug happens but had no idea how to fix it -_- 18:34
so it's kinda frustrating that I have all this time to fix bugs, but can't find any good info on what is what.... 18:35
jnthn Yeah, grasping QAST will open up quite a lot of things 18:36
Since then you'll be in a good place to deal with most things happening in Actions.nqp
The internals course goes through the various QAST nodes iirc
And gets you to build some simple compilers that spit them out
notviki I shall do it then... I never finished part 2 :} 18:37
18:51 brrt joined 19:41 Ven joined 20:01 Ven joined 20:21 Ven joined 20:41 Ven joined 20:44 TimToady joined 20:54 brrt joined 21:01 Ven joined 21:13 Ven joined 21:16 pyrimidine joined 22:47 pyrimidine joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!