Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left 00:50 frost joined 00:56 frost left 01:04 reportable6 joined 02:39 frost joined 02:54 frost left 03:54 unicodable6 left, reportable6 left, bisectable6 left, linkable6 left, tellable6 left, squashable6 left, evalable6 left, sourceable6 left, greppable6 left, releasable6 left, bloatable6 left, shareable6 left, notable6 left, nativecallable6 left, coverable6 left, quotable6 left, statisfiable6 left, benchable6 left, committable6 left, squashable6 joined, unicodable6 joined, reportable6 joined 03:55 quotable6 joined, statisfiable6 joined, notable6 joined, greppable6 joined 03:56 tellable6 joined 04:54 releasable6 joined 04:55 evalable6 joined, sourceable6 joined, linkable6 joined, shareable6 joined 04:57 bloatable6 joined 05:54 coverable6 joined 05:55 benchable6 joined 05:56 committable6 joined, bisectable6 joined 06:02 reportable6 left 06:05 reportable6 joined 06:54 nativecallable6 joined 08:50 linkable6 left, evalable6 left, brrt joined, linkable6 joined
Nicholas good *, #moarvm 09:12
jnthnwrthngtn moarning o/ 09:15
Nicholas \o 09:16
did you remember to bring your commit with you to the office today?
jnthnwrthngtn Tuesday is a home day :) 09:19
dogbert17 jnthnwrthngtn: have you had any coffee yet or do you start with tea? 09:27
jnthnwrthngtn Start with coffee. Still on the first cup 09:31
09:52 evalable6 joined
brrt we probably need to clean up the issues queue for a bit... 10:09
Geth MoarVM/new-disp: f2617a6148 | (Jonathan Worthington)++ | src/core/hll.c
More reliable resolution of current HLL

This way will be in sync even if we're between dispatchers. Fixes not using the correct HLL method not found handler.		 10:11
jnthnwrthngtn m: say 1334 / 1349 10:12
camelia 0.988881
timo hey look we're at four eights! 10:13
jnthnwrthngtn :)
I think this means a rebase alone would get us to 99% :)
timo industry standard measurement of implementation specification requirement fulfillment
MasterDuke jnthnwrthngtn: after you do a rebase it would probably be good to re-gen the ops and redo the new bootstrap. they should shrink in size since now the deprecated ops should be excluded 10:16
unrelated question. any reason not to create templates for (get|bind)attr_*? 10:22
10:22 brrt left, Kaipi joined 10:24 Kaiepi left
MasterDuke the lego jit just calls MVM_repr_get_attr_*, which recreate the body of the op in interp.c (i.e., throws an exception if it's not concrete, then calls REPR(object)->attr_funcs.get_attribute). should the template just call the same function, or should it do that concrete check and repr call itself? 10:26
timo , 10:27
(sorry, cat on numpad again)
jnthnwrthngtn: when i implemented a first draft of DispOpcodeGuardArgLitStr i had to decide whether we should add an sp_guardlitstr or sp_guard_this_integer_is_1 and put an eq_s in front. how do you feel about that? 10:29
MasterDuke i guess it would be better to do it in the template, because the maybe some of the tiles can be eliminated
timo there's still the exciting question of whether we can implement devirtualization in the exprjit, too (which really would just be constant propagation there) 10:30
jnthnwrthngtn timo: Probably the eq_s way, then we can re-use it for the other literal guards too
timo got an idea for the name? sp_guardtrue? sp_guardtrue_i? 10:31
or perhaps it'd be more like sp_guard_i and it'd take a second argument to compare against, for cases where we already actually have an integer to compare to?
jnthnwrthngtn sp_guardnonzero is especially clear I guess :) 10:33
m: say 1335 / 1349 # One needed a spectest itself tweaking 10:34
camelia 0.989622
jnthnwrthngtn So close to 99% :)
timo oh indeed nonzero reads much better thanks 10:35
MasterDuke oh, i thought we could now throw in templates, but it looks like not. just calling the function it is then... 10:36
huh. there is a throw_adhoc macro, but no templates use it 10:37
but the decoder_ensure_decoder macro does, and templates do use that 10:40
timo jnthnwrthngtn: ok to commit to the disp compile branch and to re base it? 10:46
MasterDuke is !IS_CONCRETE the same as saying it is a type object? 10:47
jnthnwrthngtn MasterDuke: yes 10:48
MasterDuke thanks
jnthnwrthngtn timo: It's OK, but I've got a local commit where I've started to integrate some of those things, but I restructured it quite a bit. OTOH most of what you do can be stolen into new-disp atop of the tweaked structure (and the new guard ops will be just the same) 10:49
m: say 1336 / 1349 # finally over 99%?
camelia 0.990363
jnthnwrthngtn Yay :)
And also I think we're down to 10 test files if we exclude those that a rebase would sort out 10:50
timo some of "those" things? 10:52
10:53 sena_kun joined
jnthnwrthngtn timo: The work on compiling dispatch programs 10:54
sena_kun I wanted to suggest a Blin run, but it's likely a bad idea until we fix the hang-ram-eaters.
tellable6 2021-07-24T13:21:53Z #raku-dev <patrickb> sena_kun: I'm available.
Geth MoarVM/translate-disp: ba433c3eb1 | (Jonathan Worthington)++ | 5 files
Start to translate dispatch programs in spesh

This gets us able to translate some dispatch programs with basic guards and producing a result which is a value. Thanks to timo++ for a first draft, which I borrowed some of the code here from.		 10:55
jnthnwrthngtn timo: ^^ fyi, not yet in new-disp because it blows up a load of tests, probably because of a bug in spesh version splitting 10:56
Nicholas what is "spesh version splitting" or is it rather too long to explain?
jnthnwrthngtn ah, sorry: SSA version splitting 10:58
Nicholas aha right thanks
timo cool, i see that it supercedes the other branch
jnthnwrthngtn timo: Yes, but a lot can still be stolen from the other branch 10:59
timo: But I'd rather introduce things a bit at a time and see there's not spectest regressions
timo is the explosion you're seeing an assertion failure for deopt_idx < 0 || deopt_idx > deopt_seen or something along those lines? 11:00
jnthnwrthngtn I don't think it was an assertion failure, I think it just ended up with bogus register eliminations and similar due to the version split going wrong 11:01
And that let to all kinds of bogosity
timo OK, interesting. i guess i'll just have to see if i can reproduce that one reliably and figure it out if nobody beats me to it
jnthnwrthngtn Note that in a commit already on new-disp I fixed the problem with it deopting to the wrong place 11:02
by making dispatch ops a predeoptonepoint
timo i thought i had that one as well 11:03
jnthnwrthngtn I don't think so; or at least, I saw a commit making sure there was a comment explaining the problem :)
MasterDuke hm. the unbox_* templates don't do the checking if it's concrete. but they are also calling repr functions... 11:08
but the lego jit is doing the same thing as with the *_attr_* ops, calling a function that does that check 11:09
is it really safe for the templates to not have that check? 11:11
timo i kind of feel like we should turn MVMSpeshIns = alloc, ->info = op, ->operands = alloc into a little helper function 11:20
the size of the operands array is helpfully included in the ->info! 11:21
Nicholas jdv: 11:22
oops
jnthnwrthngtn: with all the MVM_* environment turned on, I see 3 out of 3 fails for t/02-rakudo/18-pseudostash.t
oh, I'm out of date again. Retest... 11:23
nine MasterDuke: well the plan is usually to pull out such checks into guards and have them early in the speshed version, so not all ops have to check the same things over and over 11:33
MasterDuke hm. at least in this case, there aren't any sp_unbox_* ops. i guess i need to look in src/spesh/optimize.c and see what happens there? 11:38
i see things like github.com/MoarVM/MoarVM/blob/mast...1261-L1266 but does the jit know about that? 11:39
timo hum. the theoretical op could even use var args for operands 11:42
not op, function. helper function.
i wonder if that actually makes things easier 11:43
i think i might know what i've done wrong in the other implementation attempt 11:46
MasterDuke you know, that's something i don't actually have any idea about. how does spesh allow/prevent something from being jitted? 11:58
timo spesh itself doesn't
Nicholas actually it fails for me without MVM_* set 11:59
timo you'll want to look at the reprs to see how unboxing is optimized
we rewrite many unboxes into like sp_get_i64 and such
12:02 reportable6 left 12:03 reportable6 joined
MasterDuke well, here's a more generic question. can the template jit ever exclude checks that the lego jit does (assuming they're needed to be done by the lego jit for correctness)? 12:04
so if spesh can't re-write unbox_i into something else, do both jits need to perform all the checks that the interpreter version does? 12:05
timo i think probably yeah, though the jits also have access to the facts so if there's like a "known to be concrete" fact set, it could skip that check 12:06
MasterDuke hm, i guess those were really two distinct questions 12:08
your yeah was to the second?
timo yes for the second 12:10
but also, this means that the exprjit could exclude some checks, but that would depend on knowledge we have at run-time, so not something you can just put into a template right now 12:11
jnthnwrthngtn: is there any specific reasoning for when we use an enum vs when we do a bunch of defines? like the spesh disp opcodes for example 12:12
are an enum, whereas the types of thing that can be in an inline cache entry are ifdefs
wait, it was me who made these last ones wasn't it 12:13
MasterDuke so it seems to me that a bunch of the templates are currently missing checks that they really should have
timo it was, haha 12:14
jnthnwrthngtn Nicholas: Yes, that one fails even with the default config. Didn't dig into it yet; was still hoping it would turn out to be an NYI to blame, but I'm running out of those. 12:16
Nicholas better have a long lunchbreak then... 12:23
jnthnwrthngtn Already did lunch; I need to spend a couple of hours on something else before I look at more new-disp things 12:26
timo i think there might not be any spectest fallout from implementing just GuardArgLitStr because every program that has that also uses LoadConstObjOrStr to get the result to return 12:32
12:38 rypervenche left
timo the compile-to-spesh function now also puts spesh comments for the opcodes used to generate stuff 12:44
12:50 brrt joined
MasterDuke hm, can we use functions that return c-strings in templates? 12:55
timo probably, it's no different from a regular old pointer 12:58
if we have to MVM_free them afterwards, we can probably even do that
13:08 brrt left 13:38 rypervenche joined
MasterDuke ah, that was a red herring. calling a function that returns a c-string is fine, but the ^throw_adhoc macro needs a message known at compile time. so `MVM_exception_throw_adhoc(tc, "foo %s bar", MVM_6model_debug_name(tc, obj))` can't be done 13:45
ugh. so it's back to just calling MVM_repr_bind_int 13:47
jnthnwrthngtn Could extract the error throwing function and call that from the JIT 13:58
MasterDuke is this github.com/MoarVM/MoarVM/blob/mast...ph.c#L1649 call to jg_sc_wb really needed for bindattr_* when there's an MVM_SC_WB_OBJ call already in the function the jit is calling github.com/MoarVM/MoarVM/blob/mast...onv.c#L742 ? 14:00
timo moar: src/spesh/codegen.c:326: write_instructions: Assertion `deopt_idx < 0 || seen_deopt_idx' failed. 14:03
make: *** [Makefile:1261: m-install-post] Aborted (core dumped) 14:04
at the end of the codegen function it goes through all the annotations and has this check 14:26
if (deopt_idx == ann->data.deopt_idx)
seen_deopt_idx = 1;
could very well be that DEOPT_PRE_INS, the new one, deliberately changes the deopt index to be different? 14:27
the check would succeed for the DEOPT_PRE_INS annotation, but i'm not exactly sure if that branch should do this: 14:28
g->deopt_addrs[2 * ann->data.deopt_idx + 1] = ws->bytecode_pos;
probably not. so maybe it should just do the if check up above and set seen_deopt_idx when that succeeds
in any case the abort no longer asplodes. i can't tell if it's actually correct, or if the DEOPT_PRE_INS has to perhaps also prevent this = ws->bytecode_pos from happening, or if that doesn't matter since they have different deopt indices already anyway 14:30
14:39 brrt joined
brrt by the way, where's the channel logs these days? 14:39
Nicholas colabti.org/irclogger/irclogger_logs/moarvm 14:40
timo oh hey brrt howdy?
MasterDuke lizmat is also logging them
brrt: how difficult would it be to get non-compile-time-known messages possible for ^throw_adhoc? 14:41
lizmat logs.liz.nl/moarvm/today
MasterDuke logs.liz.nl/moarvm/index.html
Geth MoarVM/extra-translate-disp: beb2d96e59 | (Timo Paulssen)++ | 9 files
add sp_guardnonzero, use it for DispOpcodeGuardArgLitStr

also create MVM_disp_opcode_to_name to stringify opcode numbers		 14:47
MoarVM/extra-translate-disp: 9a52ca8e75 | (Timo Paulssen)++ | 2 files
implement opcodes set constant int and set result int, fix(?) codegen.
brrt MasterDuke: probably very finnicky, what did you have in mind? 14:50
but pretty possible, it's a matter of using the result of 'sprintf' 14:51
or whatever you used to construct the message
MasterDuke i was just trying to do something like `^throw_adhoc (&CAT3 "some text" (call <some func that returns a c-str>) "some more text")` 14:52
jnthnwrthngtn OK, I think I got the gremlins out of translate-disp-ops 15:02
Geth MoarVM/translate-disp: 7fbc3a6e00 | (Jonathan Worthington)++ | src/spesh/disp.c
Make our own copy of the args registers

Since we mutate these as we go about adding guards, but need to leave the original instruction untouched; otherwise deletion of it fails.		 15:08
Nicholas jnthnwrthngtn: does that want testing?
jnthnwrthngtn Nicholas: I'll merge it into new-disp soon I expect. 15:09
There's one more commit I was making sure is really effective (it is) that I'm about to push 15:10
Geth MoarVM/translate-disp: 09718d4020 | (Jonathan Worthington)++ | src/spesh/manipulate.c
Correct SSA version splitting

We need to visit all of the successors, not just the (dominance) children, otherwise we miss things that need to use the new version.		 15:12
jnthnwrthngtn There we go. Alas, there's one additional make test failure
Hm, this is bizzare 15:19
Geth MoarVM: MasterDuke17++ created pull request #1523:
Templates for (bind|get)attr(s)?_*		 15:33
jnthnwrthngtn Ah, deopt bug. Thus why the feeling of crazy 15:34
Geth MoarVM/translate-disp: fd010c1197 | (Jonathan Worthington)++ | src/spesh/usages.c
Properly account for pre-deopt points

We need to add deopt usages for the *reads* of an instruction if we are going to deopt to before it, otherwise the operands it needs shall be missing.		 15:43
MoarVM/new-disp: 4 commits pushed by (Jonathan Worthington)++ 15:47
jnthnwrthngtn OK, translation and spesh of the most basic dispatch programs is in
MasterDuke noticeable change in rakudo build times? 15:48
jnthnwrthngtn (Guards + returning an object constant)
MasterDuke: I was so focused on fixing the bugs I didn't pay any attention, alas
This doesn't yet deal with any of those involved with method calling etc. 15:49
MasterDuke brrt: while you're here, github.com/MoarVM/MoarVM/pull/1523 look correct? 15:50
jnthnwrthngtn timo: fwiw, I don't hit that assert on `make install`, and I think I've got a debug build 15:51
Language class time now, but I get hits with adding just MVMDispOpcodeUseArgsTail and MVMDispOpcodeResultBytecode to the allow list (it then blows up 'cus I didn't really process them yet). 15:56
So I might tackle that next
Nicholas have fun 15:57
jnthnwrthngtn Where "next" could well mean "tomorrow" :)
timo jnthnwrthngtn: yes i only hit it after implementing one of the disp opcodes 17:01
how does jnthn count the successfully running spectest files btw? i'm getting the impression a bunch more are failing on my end, but i haven't rebased rakudo on latest master yet 17:21
jnthnwrthngtn make spectest | grep '\. ok' | wc -l 17:25
There are around a dozen failing, I also don't have Inline::Perl5 installed, so don't run those ones yet, so there may be some failures there too 17:26
timo OK let's see 17:27
it goes above my scroll buffer limit :|
i'll have to run it again
jnthnwrthngtn Yeah, I'm redirecting it to a file and then counting that and I can also look at what's newly failing if the number goes the wrong way 17:28
timo should we go to run "stresstest" instead of spectest? 17:29
sena_kun jnthnwrthngtn, there is a failure in Inline::Perl5 installation at least, it gives off an odd error: 17:45
jnthnwrthngtn So long as there's things to do with spectest, I don't see the benefit yet
sena_kun [Inline::Perl5] P6opaque: no such attribute '$!do' on type Code in a Scalar when trying to get a valueCompilation failed in require at (eval 1) line 158.
===SORRY!===
No registered operation handler for 'multicacheadd'
it's a single occurrence of something that complains about `multicacheadd`
jnthnwrthngtn Ah, well, that is gone and not coming back
sena_kun oh, fixed?
jnthnwrthngtn No, I mean, nqp::multicacheadd is gone
No, I mean, nqp::multicacheadd is gone 17:46
sena_kun aaaaah
then the module itself must address that
jnthnwrthngtn Yes
But the message before that about the attribute looks like a mistake in Rakudo's dispatchers
Can't immediately guess where
But that is something for me (or anybody else who fancies debugging it) 17:47
sena_kun jnthnwrthngtn, it certainly needs some focus and it's evening already...
jnthnwrthngtn I have a feeling Inline::Perl5 is going to get to suffer twice (new-disp, RakuAST)
:(
sena_kun: Yes, but baked potatoes take a long time to bake... :) 17:48
sena_kun has fixed the $dayjob thing
jnthnwrthngtn I'm doing the slightly easier task of preparing for spesh of some dispatches that lead to bytecode invocation though :)
yay
timo why do baked potatoes take a long time to bake when they are already baked potatoes? :P 17:49
MasterDuke and do twice baked potatoes take twice as long to bake?
timo is bug-coverage.t known / supposed to run a really really long time? 17:50
jnthnwrthngtn timo: It hangs because there's a long-standing bug in QAST -> MAST that was exposed 17:52
timo ah good 17:53
jnthnwrthngtn It only passed before for the very very bogus reason that the code-gen fails to emit an instruction to convert between sizes somewhere, so it reads from an int register that is "uninitialized", but previously the takedispatcher logic wrote a value into that register
Now we don't emit the takedispatcher op sequence and the bug is revealed
(Yes, that was a fun one to figure out) 17:54
timo ok, 1336 succeeded spec tests on my branch (which i just rebased onto latest new-disp half an hour ago) 17:55
17:58 brrt left
jnthnwrthngtn dinner for me, I think :) 17:59
18:02 reportable6 left
nine Actually Inline::Perl5 should already address the possible absence of multicacheadd 18:04
18:05 reportable6 joined
nine There are 3 implementations of the FindBestDispatchee module in various degrees of "pokes in internals" and I EVAL them and should fall back on the safer one 18:06
github.com/niner/Inline-Perl5/blob...HOW.pm6#L4
dogbert17 What's this: 18:11
moar: src/spesh/codegen.c:326: write_instructions: Assertion `deopt_idx < 0 || seen_deopt_idx' failed.
Aborted (core dumped)
18:11 sena_kun left
dogbert17 i get it when running t/spec/S32-temporal/DateTime.t 18:12
in order to repro it should be enough to build MoarVM with --no-optimize 18:16
timo try my branch 18:17
dogbert17 which branch is that, extra-translate-disp? 18:21
timo yes
works fine over here 18:22
dogbert17 seems to work here as well 18:23
timo now if someone could look over it and tell me if it actually makes sense how i fixed it .. :) 18:25
but for that you'll want to know how the deopt mechanism works. have fun! ahaha
dogbert17 I'll leave that to your cats .) 18:27
:)
timo will be interested to see how exactly we will implement ResultBytecode and ResultCFunction ... the first is probably just invoke_* on the NQPRoutine or similar, and the second? i assume it'll need a new op in the interpreter for invoking that kind of object? 19:11
the implementation of ResultBytecode in the disp program interpreter looks simple enough, it just calls MVM_frame_dispatch on the value in the temporary register
the other one calls the C function and then MVM_callstack_unwind_dispatch_run, which i haven't looked at yet, but since we're compiling stuff to spesh code already, there wouldn't be a "dispatch run" to unwind out of? 19:12
MasterDuke ok. so the template for unbox_i just calls the repr function directly, it doesn't do the concreteness check. how could i test whether that's ok or not? 20:19
Geth MoarVM: 2932ef5bae | (Daniel Green)++ | src/jit/core_templates.expr
Templates for (bind|get)attr(s)?_*
 20:23
MoarVM: 6412f2f985 | MasterDuke17++ (committed using GitHub Web editor) | src/jit/core_templates.expr
Merge pull request #1523 from MasterDuke17/jit_templates_for_bind_and_get_attr_ops

Templates for (bind|get)attr(s)?_*
20:23 jnthnwrthngtn left
MasterDuke nqp: my $a; my int $i := 0; my $b; while $i++ < 100_000 { if $i < 90_000 { $a := nqp::unbox_i(123) } else { $a := nqp::unbox_i($b) } }; say($a) # ah ha, i think this does it 20:24
camelia This type cannot unbox to a native integer: P6opaque, NQPMu
at <tmp>:1 (<ephemeral file>:<mainline>)
from gen/moar/stage2/NQPHLL.nqp:1946 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPHLL.moarvm:eval)
from gen/moar/stage2/NQPHLL.nqp:2151 (/home/c…
20:25 jnthnwrthngtn joined
MasterDuke the error message should be `Cannot unbox a type object (NQPMu) to an int.` 20:26
at the stack trace is in get_int->get_uint instead of MVM_repr_get_int 20:27
*and the
the throw is here github.com/MoarVM/MoarVM/blob/mast...#L524-L525 20:42
is that an ok place to throw? or should it really be from the concreteness check?
timo hum. i wonder if we have representations where it makes sense to unbox a type object 21:02
it doesn't sound like a good idea to go after the real_data if concreteness hasn't been established, however 21:06
MasterDuke it doesn't seem like a good idea, but it doesn't complain about that 21:10
jnthnwrthngtn You'll just be reading a junk value if you try to unbox a type object (whatever is some bytes after it) 21:12
timo the unbox reprop could do whatever it wants tho 21:15
MasterDuke halt and catch fire? 21:16
timo sure why not 21:17
Geth MoarVM/new-disp: d6ce0b4bb8 | (Jonathan Worthington)++ | 10 files
Spesh non-resuming bytecode dispatch terminals

Only for the common case where the arguments are a tail of the original dispatch arguments for now, however the non-tail case should not be too difficult to add either. Resuming cases will need more work, since they must leave a dispatch run record on the callstack with the required temporaries populated. This will most likely be done by emitting one or more ops to do that setup work.		 21:20
jnthnwrthngtn timo: That's how :)
Also, doesn't seem to have regressed anything. Nice. 21:21
timo whoa 21:22
oh i'm not entirely sure why it works that you can "just"™ take a piece of the bytecode bytestream and set that as the .map of the .args 21:23
but in that case a "non-tail case" would just be changing what comes at the end of the instruction where the map is taken from? 21:24
21:25 evalable6 left
jnthnwrthngtn A non-tail case changes nothing in runbytecode, but rather the code in spesh that produces it 21:25
The operands we put into the runbytecode instruction will come out of the operands temporaries and args 21:26
The tail case is really common (or rather, our dispatchers are organized so it is), and quite nice in that even in the non-spesh case it's "add to the pointer into the varargs register list" 21:27
For the spesh case the original dispatch bytecode doesn't matter 21:28
timo i'm not sure where the map is actually written, i only see that operands from the args array are put into the operands for the runbytecode op 21:29
jnthnwrthngtn Ah, I'm probably missing which bit of understanding this you're missing 21:30
timo haha
jnthnwrthngtn All dispatch_*, sp_dispatch_*, and sp_runbytecode_* are varargs ops
After the fixed part comes the list of registers that are passed as arguments in the dispatch 21:31
timo oh, using reg_base as the base means when you offset by the register numbers you'll end up at the actual register
jnthnwrthngtn Yes
timo that's tricky :)
jnthnwrthngtn It's a cheaper way of saying tc->cur_frame->work
timo i thought maps were always mostly like "1, 2, 3, 4, 5, 6, 7, 8"
jnthnwrthngtn No, that's the "identity map2 21:32
timo but with this the map could as well be like "19, 20, 15, 0, 5, 24, 25, 90"
jnthnwrthngtn Which occurs in situations where we have an MVMCapture
And so a flat array of args
timo that makes more sense now i think 21:33
jnthnwrthngtn This approach means we no longer needs a frame->args to copy things out of, which parameter binding then copies out of
uh, copy things into
timo true, we can directly access by going through the .source and .map
jnthnwrthngtn Parameter binding just does source[map[param_index]]
Since there's no prepargs and arg_* instructions any more, a call is always one instruction for the interpreter to dispatch 21:35
Not 2 + number_of_args
Hopefully this works out decidedly cheaper :)
MasterDuke prepargs is going away? nice. that's always top of the list of missing templates 21:36
timo the loop that CopyArgsTail in the disp "interpreter" does, i imagine that'll all happen to be constant at spesh-time when we translate a dispatcher? 21:37
jnthnwrthngtn Yes
timo is that all there is in terms of "not args tail"? we're just working with temporaries again, so i imagine CopyArgsTail will end up as a row of "set" instructions perhaps? 21:39
i remember stuff like "pop off the first argument" and such, but that's what you write in your dispatcher, not what ends up in the dispatch program that is made from the recording
jnthnwrthngtn It doesn't even need to emit sets
We have an args and a temporaries array of spesh operands, which tracks which registers hold those 21:40
timo in that case i don't know what the "Copy" in there even means :D
jnthnwrthngtn It *is* a copy when you're interpreting the disaptch program 21:41
In spesh the "copy" is at spesh time from the list of args operands of the unspecialized dispatch instruction into the operands of the specialized runbytecode instruction :)
So no runtime copying takes place after specialization 21:42
Oh
An alternative implementation is actually in spesh to copy operands out of args into temporaries 21:43
That may actually work out as less code
timo ah, literally take the MVMSpeshOperand structs, basically memcpy
jnthnwrthngtn Right :)
I'd not thought of that way of doing it until now, but it's probably going to be neater code
timo well, i'm glad i poked your brain about it, haha 21:44
jnthnwrthngtn Anyway, probably I should rest. :)
I'm really glad this didn't (obviously, I didn't spesh stress it yet) produce any new regressions.
timo o/ and also \o/ 21:45
jnthnwrthngtn timo: Is extra-translate-disp good for me to take some bits from tomorrow? (I'll probably cherry-pick commits into new-disp)
timo i did get 1336 passing spec tests, i think it's good, but i can't guarantee that my fix for how the deopt indices are taken from annotations is correct 21:47
jnthnwrthngtn OK, I'll look at it after some rest. 21:48
Though yeah, it's a good sign
'night o/
timo we do not only have to copy over the operands but also set up the usages. so there has to be a loop anyway. not sure if it'd be faster to memcpy first and then loop or to loop and assign as well as set the user 21:57
running spectest with spesh logs to /tmp is a *bad* idea :) 22:08
i put an abort() in the impl of copy tail and none of the spec tests asplodes with a sigabrt 22:12
22:25 linkable6 left 22:28 linkable6 joined, evalable6 joined 23:28 linkable6 left, evalable6 left 23:29 linkable6 joined
Geth MoarVM/opcode_set_and_copytail: ec6cd25096 | (Timo Paulssen)++ | src/spesh/disp.c
implementation of MVMDispOpcodeSet
 23:49
MoarVM/opcode_set_and_copytail: 4ccf0136db | (Timo Paulssen)++ | src/spesh/disp.c
implement DispOpcodeCopyArgsTail and its effect in ResultBytecode
timo some more bits you can cherrypick if they look correct enough

Powered by Cro and the Raku® Programming Language.

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

Thank you!