github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:37 lucasb left 01:10 rypervenche left, konvertex left 01:13 rypervenche joined
nwc10 good *, #moarvm 05:14
05:24 Util left 05:58 Util joined 07:27 zakharyas joined 07:30 TimToady_ left 07:33 TimToady joined 07:56 sena_kun joined 08:09 Altai-man_ joined 08:12 sena_kun left
jnthn morning o/ 09:03
nwc10 \o
09:37 konvertex joined
Geth MoarVM: MasterDuke17++ created pull request #1301:
Some staticframe fixups		 09:40
MasterDuke nwc10: ^^^ tried to add you as a reviewer, but you're not in the org anymore? 09:41
10:10 sena_kun joined 10:12 Altai-man_ left
MasterDuke .tell patrickb dev.azure.com/MoarVM/MoarVM/_build...0&l=21 not sure how it got that commit hash? it's not from my PR or MoarVM 10:21
tellable6 MasterDuke, I'll pass your message to patrickb
Geth MoarVM/new-disp: ceb20a4112 | (Jonathan Worthington)++ | src/core/interp.c
Update some capture ops to know about MVMCapture

Which will eventually completely replace MVMCallCapture.		 10:28
MoarVM/new-disp: 8f8d6765e0 | (Jonathan Worthington)++ | 3 files
Generalize boot-constant to all arg kinds

No reason we can't have a constant integer or string result of a dispatch plugin.		 10:36
MoarVM/new-disp: fb1ebe9a08 | (Jonathan Worthington)++ | 3 files
Fix dispatch callback so we can be race safe
 10:54
MoarVM/new-disp: da968a028b | (Jonathan Worthington)++ | 5 files
Prepare dispatch plumbing for other transitions

Store in the dispatch recording record the record that we initially saw, and then pass it along to the transition function, which is now generalized a little in preparation for handling the polymorphic case.		 11:11
jnthn Ah, darn, seems I shoulda made sure the ID was retained too... 11:13
lunch &
11:56 MasterDuke left 12:07 zakharyas left 12:09 Altai-man_ joined 12:12 sena_kun left 12:37 MasterDuke joined
Geth MoarVM/new-disp: 9a6b145290 | (Jonathan Worthington)++ | 5 files
Implement polymorphic dispatch

Where we stack up a number of dispatch programs at a callsite.		 13:01
[Coke] jnthn: you have 'thorugh' in a comment, should be 'through'. github.com/MoarVM/MoarVM/commit/9a...13004aR102 13:04
13:05 zakharyas joined
Geth MoarVM/new-disp: 61bee36ff3 | (Jonathan Worthington)++ | src/disp/inline_cache.c
Fix typo; Coke++
 13:06
MasterDuke i was trying to get a python program that used clang+hunspell to find and spellcheck all comments, but i could never get it working 13:09
[Coke] Could probably re-purpose the xt/aspell.t test from Raku/doc 13:10
I could give it a shot if you like.
jnthn nwc10: Hmm...no SEGV for me in stage optimize of Rakudo...though I didn't ASAN it.
MasterDuke [Coke]: go ahead, i kind of lost steam on that task 13:12
could probably use ctags to generate a whitelist of type names, function names, etc 13:15
[Coke] MasterDuke: any pointers on how to use ctags? 13:22
MasterDuke [Coke]: i'd start with something like `ctags -R -x src/*` in the moarvm directory 13:30
[Coke] illegal option -- R is not a good start. :) 13:31
MasterDuke huh. --recurse? 13:32
[Coke] I'll see if macports has a version.
I can't even do -v or --version to see what's what. lovely. :)
MasterDuke the -x gives you a human readable version 13:33
there are also some options for limiting to certain things you could play around with, e.g., `--c-types=f` for just functions 13:34
but the default will probably get you 95% there
Geth MoarVM/new-disp: 316063d6d6 | (Jonathan Worthington)++ | src/disp/program.c
Finish not-object-literal guards

These exist mostly for handling of bottom values, notably Nil in Raku.		 13:37
jnthn Phew. 13:42
That's all the kinds of guards implemented and test covered.
Geth MoarVM/new-disp: 8d636adb41 | (Jonathan Worthington)++ | src/disp/program.h
Remove a TODO about num_ops field

We could maybe get away with it, but we're a bit more robust knowing it.		 13:49
jnthn Looks like I might be able to switch one Rakudo dispatch plugin over already. The rest after this will need attribute fetch/guard and to do the pre-flattening thing 14:03
14:10 sena_kun joined 14:11 Altai-man_ left 14:12 MasterDuke left
timotimo exciting 14:26
jnthn Will probably do those bits before I get to the spesh wiring, fwiw 14:32
timotimo you're saying there is perhaps a chance for me to get the spesh codegen in before you get to that? :) 14:33
jnthn Perhaps so. The plan there is to make a spesh log entry with the index of the dispatch program (0 for monomorphic cases) that was picked 14:34
So we can then correlate it with the args etc. like we do other invocations today
timotimo ah, yes
jnthn (Much like how spesh plugins work too, actually)
timotimo so we'll be able to see when one guard almost always is the right one and only codegen that one 14:35
jnthn Yup 14:49
Though if it's really polymorphic we can think about emitting a branching structure.
language class, bbiab 14:52
14:57 lucasb joined 15:12 zakharyas1 joined 15:15 zakharyas left 15:53 MasterDuke joined 16:09 Altai-man_ joined
jnthn back 16:11
16:11 sena_kun left
timotimo i didn't do anything in the mean time, lol 16:14
but i did try out the code and found some ways for things to crash
one is that the new call stack regions aren't understood by the GC yet, and rarely you can hit one
i couldn't reproduce inside gdb just yet, so don't know which number was hit, and when/where
build_cfg in spesh also seems to not understand the varargs yet maybe? 16:15
so i'll just look into that last one for now 16:16
jnthn Yeah, it needs to learn about dispatch, I think 16:20
The call stack regions are marked but they should panic and say the mark is NYI so far
If they're doing segv that's unexpected, the "please implement me" panic is expected
I just wanted to test case that hits it before I implement it
timotimo yes, right, it's an nyi panic 16:24
jnthn OK, "good" :) 16:25
timotimo until now we had varargs special-cased for PHI already by building fake info entries 16:26
we may want to do the same thing for dispatch ops
Geth MoarVM/new-disp: 8fb1269775 | (Jonathan Worthington)++ | src/6model/bootstrap.c
Add missing setup of BOOTCapture and BOOTTracked
 16:27
jnthn Maybe, yes
OK, yay, with that I can make it into a (very incomplete) return value dispatcher, which I can now fill out 16:29
timotimo i'm allowed the "blah = { .foo = 1, .bar = 2 }" (or whatever) syntax as well? :3 16:35
oh, is that only for initialization, not when i've got a pointer that i spesh_alloc'd for example?
memcpy could be nicer here anyway 16:36
16:39 mst left, BinGOs left
jnthn Well, got part of the return value type check plugin going 16:49
then boom segv
Oh, I didn't disable spesh
Wonder if it'll be in there
(it'll not have a clue what to do, so... :)) 16:50
haha, yes, in spesh graph
16:51 MasterDuke left
jnthn With spesh disabled it gets through `make` in Rakudo with the spesh plugin swapped out for an (incomplete) dispatcher doing return value type checking 16:54
nine That sounds like a major mile stone :) 16:57
jnthn Encouraging at the very least. :) 17:00
I note the identity case with dispatchers is a bit nicer, 'cus we don't need an identity sub any more, we just tell it to make a result by picking a value out of the capture 17:01
Which means there's no bytecode-level invoke (and so no MVMFrame) in the happy path there any more even pre-spesh (and spesh will be able to avoid dealing with inlining the identity frame too) 17:02
Not that inlining the identity function is a huge job, but it's still a job, and it still bloats up the inlines table 17:03
timotimo hum, isn't a prepargs op supposed to come right before a dispatch op? 17:07
(gdb) print ins_flat[ins_idx][0].info[0] 17:08
$22 = {opcode = 825, name = 0x7ffff7a5d043 "dispatch_v", num_operands = 2, pure = 0 '\000',
jnthn No
timotimo (gdb) print ins_flat[ins_idx -1][0].info[0]
$23 = {opcode = 597, name = 0x7ffff7a5c53f "const_i64_16", num_operands = 2, pure = 1 '\001',
jnthn dispatch is a standalone instruction
timotimo isn't? d'oh
jnthn It contains the callsite index
timotimo oooh, that's how it works 17:09
jnthn So you look up the callsite by the index in the dispatch instruction
timotimo wow i am not smart :) :)
jnthn ;)
timotimo i only saw that the validator looks at -2 for the callsite index
jnthn That's a bit self-harsh...it is a departure from every other invoke-y thing in MoarVM to date :)
I do wonder how much of a saving we'll get when interpreting from the fact that a call with 2 args will be 1 interp instruction dispatch instead of 4... 17:10
timotimo aye 17:12
jnthn Another nice little thing: the spesh plugin approach would make a closure each time when it had to take the slow-path on return.
Now it can just shuffle an extra argument into the capture
That's a triple win. 1. less memory for all those closures. 2. lower cost of lookup of the things it needs to work on. 3. things that are constants are far more obvious to spesh. 17:14
timotimo why are MVMCallsiteFlags values for obj, int, num, str individual bits rather than being masked like for op info flags 17:23
jnthn Less pressure on the bits, maybe 17:27
timotimo umm, huh 17:29
ah, right
we don't support lexical arguments to dispatch_*
jnthn Lexical arguemnts? 17:30
timotimo so i don't need a bit in callsite for "is it a lexical"
jnthn Ah, no, they have to be loaded into a register first :)
timotimo so they're either literal or register
jnthn Well, actually...
*everything* is register
Even literals
There's no direct argconst equivalent
The literal bit just a hint to the dispatch mechanism that the argument may be considered a constant 17:31
So it can not emit a literal value guard
It does anyway for objects at the moment, mind
'cus the bytecode validator isn't smart enough to prove it was a wval
timotimo ah, interesting, ok 17:32
jnthn Hmm, "Unknown dispatch program op 20" :) 17:33
Ohhh...I think I know what I forgot to implement
But I also want some dinner :)
timotimo i have to afk a little bit as well 17:35
17:43 squashable6 left
nine How can this nested block's frame github.com/rakudo/rakudo/blob/mast...le.pm6#L56 have a tc->cur_frame->outer->outer that doesn't appear in the tc->cur_frame->caller chain? 17:46
17:46 squashable6 joined
nine Because that's what happens: in the caller chain, a lexical gets initialized (often an argument) but some nested block (i.e. a closure) looks in the appropriate outer, finds a different frame there and doesn't find a value for that variable. 17:47
17:55 zakharyas1 left 18:10 sena_kun joined 18:12 Altai-man_ left
timotimo nine: something about how we put exception blocks on top of a call stack? 18:36
19:11 AlexDaniel left
nine timotimo: my suspicion runs more in the other direction. The call stack is a pure runtime thing that can hardly go wrong. The frame that called this frame will be there. But how does a frame get its outer? That's more likely some compiler influenced thing that in many cases won't show up when its wrong as not all code even accesses the outers 19:41
19:47 zakharyas joined
timotimo hmm 19:49
the outer is static, except when forceouterctx hapens maybe?
nine Also it's not just exceptions. Another case was a closure passed to grep 19:58
20:09 Altai-man_ joined 20:12 sena_kun left
timotimo ok 20:14
jnthn nine: Not an effort of autoclose, maybe? 20:21
(Disclaimer: brain full of dispatcher stuff, so haven't looked closely...)
timotimo ok so i see a bunch of op info structs being built during make_cfg 20:30
then my loop runs another ~150 repetitions and then it crashes while trying to validate an ext op record that is a bit out of range 20:31
nine I've traced tc->cur_frame->outer's origin back through several garbage collections to a clone call on the block. The source of the clone is a frame created by capturelex 20:32
timotimo dispatch_v lits(bad-dupe), callsite(0x1704310, 1 arg, 1 pos, nonflattening, interned) # [008] JIT: bailed completely because of <dispatch_v>
nine That happens in gist.github.com/niner/5148f4e6f7e5...be3bd2ae6e
timotimo ii wonder if it's grabbing the op info from the opcode - at least in log dumping 20:33
hm, no, it's grabbing ins->info->num_arguments 20:34
ah of course 20:35
const_i64_16 r8(1), liti16(42) 20:36
[Annotation: 13 (unknown)]
dispatch_v lits(bad-dupe), callsite(0xbe7720, 1 arg, 1 pos, nonflattening, interned), r8(1) # [008] JIT: bailed completely because of <dispatch_v>
jnthn looks like progress 20:39
Geth MoarVM/new-disp: 9f0f25d3cd | (Timo Paulssen)++ | src/spesh/graph.c
invent MVMOpInfo struct for dispatch_* var-args ops
 20:44
timotimo it still crashes with that out-of-range opcode, but i'm not sure why 20:45
nine Either my ack foo is failing, or we actually don't generate any blocks with blocktype 'immediate_static', ever. 20:46
Geth MoarVM/new-disp: 653702ecd6 | (Jonathan Worthington)++ | 2 files
Interpret MVMDispOpcodeCopyArgsTail

Which turned out to need the callsite, so the setting up of the callsite now goes with the arg setup ops, which makes more sense anyway since now all population of MVMArgs is done in a single op rather than being spread over a couple.		 20:48
jnthn nine: I can believe that is the case 20:49
nine Yeah, looks like it. So it must be 'declaration_static' 20:53
20:54 zakharyas left, Altai-man_ left
timotimo looking into a spesh log struct and function for dispatch program choice 21:01
the "plugin" piece of the spesh log struct could be usable for this? uint32 bytecode_offset, uint16 guard_index 21:04
Geth MoarVM/new-disp: e8cd627dcc | (Jonathan Worthington)++ | 3 files
Add GC marking of dispatch programs

As well as detecting any inline cache entries we may have forgotten about.		 21:05
jnthn Yes, that may well work
Just make sure the bytecode offset calculation exactly matches the way used for the inline cache lookup 21:06
So that we can dig up the correct inline cache entry later
timotimo yeah i was just about to steal the bytecode offset logic from spesh plugin resolve, where it's passed in from interp.c or the jit 21:12
or as a literal from spesh i guess
the cat now has her feet sprawled out above my keyboard again 21:15
jnthn An amount of `make test` now passes with using dispatch instead of spesh plugin for return values. There's a couple of segvs that I think I can guess what are, a code-gen bug responsible for probably most of them, and then that I didn't yet implement coercion handling of return types in the dispatcher version. 21:18
Actaully a majority of make test
Think I'll go rest a little now 21:19
[Coke] jnthn++ 21:24
21:53 AlexDaniel joined, AlexDaniel left, AlexDaniel joined, MasterDuke joined 21:59 MasterDuke left 22:18 MasterDuke joined 23:33 leont left 23:34 lucasb left
timotimo gist.github.com/timo/ae05d4ac8a072...1e571cd716 - dispatch results landing in the spesh log and being incorporated into the stats - though currently it makes no difference between spesh plugin and disp program at all. that is probably not an issue, though, since we wouldn't have a dispatch and a spesh plugin on the same address? 23:41
Geth MoarVM/new-disp: 28fdfe3b41 | (Timo Paulssen)++ | 7 files
log dispatch resolution and incorporate into stats

currently looks exactly like a spesh plugin guard index in the stats, but there shouldn't be a conflict, i don't think.		 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!