github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke huh, the interp.c implementation of speshresolve is the only op (based on some quick searching inside interp.c) that uses cur_op minus some value (2 in this case) 00:10
jnthn It gets called when there's no matching guard set, thus why I suspect the guard set being installed doesn't match the values beign passed. 00:11
MasterDuke i guess i'm not sure how to check that 00:12
jnthn Maybe instrument the plugin to see what path it takes and what speshguard instructions it calls to set up the guards, and see if some don't match what's being returned 00:14
MasterDuke i got this info, `Orig_type = Int:D and type = Int and definite_check = 1 and nqp::iscont($rv) = 0 and rv = Nil and nqp::isnull($coerce_to) = 1` 00:16
that's happening 29.5k times
so `nqp::speshguardtype($rv, $rv.WHAT);` is called unconditionally, `nqp::speshguardconcrete($rv);` is called because `$definite_check == 1` 00:18
and then `&identity` is returned 00:19
oh ho! 00:25
changing github.com/rakudo/rakudo/blob/mast...s.nqp#L260 from `elsif $definite_check == 1 { nqp::speshguardconcrete($rv); }` to `elsif $definite_check == 1 && !!nqp::istype($rv, Nil) { nqp::speshguardconcrete($rv); }` seems to fix things 00:27
time is down to 0.5s and maxresident is down to 89m 00:28
jnthn: ^^^
oops, that's a typo in pasting here, it's only one ! 00:29
jnthn MasterDuke: Ah, that sounds like a reasonable change 00:35
Nice :)
MasterDuke heh, and now there are not 29.5k calls to the plugin 00:36
i'll spectest and then PR assuming it passes 00:37
still none of the 6 different index calls are getting jitted 00:43
jnthn Maybe the index op itself doesn't have a jit mapping 00:54
MasterDuke hm, i'll take a look 00:55
jnthn: btw, just got a single spectest fail in t/spec/S32-temporal/DateTime.t
jnthn MasterDuke++
MasterDuke `Type check failed for return value; expected Int:D but got Int (Int)` 00:56
jnthn Hm, that almost looks legit...I wonder if you've fixed a bug too?
Sleep time for me; back tomorrow o/
MasterDuke jnthn: i'm not sure i understand well enough to say. i'll probably make a PR as is and let you decide when you want to take a look 00:57
looks like there is both a lego jit implementation and a template for index_S 00:58
*index_s
01:00 lizmat joined, p6bannerbot sets mode: +v lizmat 01:05 lizmat left
MasterDuke timotimo: any idea if speshresolve can be jitted the same way sp_speshresolve is? 01:11
01:15 test123_ joined, p6bannerbot sets mode: +v test123_ 01:37 test123_ left 02:14 Ven`` left 05:08 MasterDuke left 06:16 Kaiepi left, Kaiepi joined 06:17 p6bannerbot sets mode: +v Kaiepi 06:58 domidumont joined 06:59 p6bannerbot sets mode: +v domidumont 08:10 evalable6 left 08:11 evalable6 joined, p6bannerbot sets mode: +v evalable6 08:19 zakharyas joined 08:20 p6bannerbot sets mode: +v zakharyas 09:33 lizmat joined, p6bannerbot sets mode: +v lizmat 09:59 robertle left
jnthn speshresolve should always be turned into sp_speshresolve, I thought. 10:44
11:40 robertle joined 11:41 p6bannerbot sets mode: +v robertle 11:44 brrt joined 11:45 p6bannerbot sets mode: +v brrt
brrt ohai #moarvm 11:45
lizmat brrt o/
brrt \o lizmat
how's things?
(I can wait with complaining about the difficulties imposed by polymorphism a bit longer) 11:46
lizmat my back hurts like hell since the past weekend 11:47
brrt how so?
lizmat other than that, all is fine :-)
brrt :-) hope it gets better soon
lizmat age, lack of exercise, too much food and drink
lizmat too
:-)
nwc10 get well soon, lizmat 11:49
lizmat ah, having been in the car for 4 hours and sitting on less than adequate seating for 5 at the Amsterdam.PM meeting didn't help
nwc10: thanks :-)
nwc10 clearly it's all Asterdam.PM's fault, for being in Amsterdam.
lizmat well, that would account for the 4 hours in the car :-) 11:50
TechInc, the amsterdam hackspacem, would account for the other 5 :-)
but mostly it's age and not enough exercise recently 11:51
brrt If it's a 4 hour road trip back and forth to amsterdam, I wonder if the train wouldn't be faster? 11:55
lizmat nope, train takes 2.45 hour each way
brrt Not that train seats are ideal
oh, that sucks
lizmat well, that's not true
it took me to B. 2h45 minutes each way
nwc10 and B. is near a station, isn't it? 11:56
lizmat that includes roughly 20 mins from Amstel to B. and 10 min from home to Echt station
nwc10 oh, I'm confused/confusing things. What's new?
lizmat B. used to be near Weteringcicruit at the time
B. is now near a metro stop 11:57
brrt there's like so many B. offices
nwc10 "is it Friday?" "no" "how about now?"
lizmat well, the B. office I needed to go to :-)
brrt :-)
Yeah, I've been there as well
it's solely customer supports these days
or last year anyway
Now it's near the Waterlooplein 11:58
But there's also a big office at Vjjzelstraat
(my knowledge of Amsterdam topology is limited solely to B. offices, actually) 11:59
lizmat the new head office of B. is now being built near CS 12:00
(as in Central Station)
static0.persgroep.net/parool/image...RFo0T1RJeQ 12:01
brrt I recall that, and thinking 'that's both far too large, and too small' 12:02
lizmat yup
brrt anyway. back to my regularly scheduled complaining 12:03
so. `bindlex` is a polymorphic opcode
among other things, it might take a `num64` value to assign
this is no problem for MoarVM because it treats the register as a bag-of-bits 12:04
It is a somewhat bigger problem for the expression JIT because it may well have allocated the value-to-be-assigned to a register, and that register will be a FPR register
The expr template builder has the information at runtime whether the bindlex will assign to a num or int register 12:08
so that's good...
but the actual template doesn't know that, so it uses a `store` operator rather than `store_num`
Now... I don't actually *need* the distinction of operators. The tiler can select the right one 12:09
i.e. anytime where the runtime tree would yield a (store ? num), the tiler will do the right thing. This is not true for load_num; we need that 12:10
because it yields a differently typed value
my learning here is that load isn't polymorphic because it yields a distinct type, but that store is polymoprhic because it consumes multiple types and yields a single one 12:11
alternatively, I make the expr tree builder insert the store for bindlex 12:22
much like it does for `set`
dogbert2_ lizmat: do you have access to a product called Voltaren? 12:23
brrt ... but I'm liking the polymorphic solution better
lizmat dogbert2_: no
lizmat looks it up
dogbert2_ It's an NSAID painkiller with anti inflammatory properties 12:24
could have another name where you live though
lizmat yeah... looks pretty heavy
I'm not in that stage just yet :-) 12:25
dogbert2_ it has saved me a few times :)
12:26 zakharyas left
lizmat thanks for the suggestion :-) 12:26
dogbert2_ only necessary if the normal painkillers (the ones used when you have a headache) doesn't do the job 12:28
lizmat yeah, they're working for me, allowing me to sit at my desk and writing this :-) 12:31
12:39 lucasb joined, p6bannerbot sets mode: +v lucasb 12:55 brrt left 13:01 robertle left 13:03 robertle joined 13:04 p6bannerbot sets mode: +v robertle
timotimo i think voltaren is over-the-counter in apothecaries in germany 13:04
jnthn So...time for more debugging... 13:10
I really like how the first letters of Dead Instruction Elimination spell "die" :P 13:11
I less like that doing more of it causes some weird at-a-distance deopt bug :S 13:12
timotimo spooky action-at-a-distance, more appropriate than ever 13:14
jnthn :)
I think I'm going to find/look at a different failing test that might be more isolated
Or at least maybe more localized 13:15
oh wow 13:18
The exact same failure mode shows up in a ton of NQP tests with nodelay...
nwc10 MVM_SPESH_NODELAY for the win 13:21
or at least, fail early, fail often
jnthn Yeah, though this means it's better for me to continue debugging the case I already was.
nwc10 is a bit surprised that more folks aren't setting MVM_SPESH_NODELAY and its awkward squad friends more often when developing
jnthn All the failures I can see boil down to the sequence of a `mixin` with a few more instructiosn deleted leading to, when it triggers global deopt, some problem with the deopt and uninline of !reduce a stack frame or two down 13:23
13:25 Ven`` joined 13:26 p6bannerbot sets mode: +v Ven``
jnthn Aha, progress-ish. So it turns out that while it breaks when the spesh limit is set so mixin is the final frame that it specializes...that is because only that being specialized triggers the global deopt needed to expose the bug 13:35
If I make it refuse to delete inilined instructions inside of !cursor_pass *then* I get the explosion 13:36
oops
Then I *don't* get
So it's actually the delete in there that is "the problem", but we need to optimize something else too in order to ever hit that situation. 13:37
13:40 brrt joined 13:41 p6bannerbot sets mode: +v brrt 13:49 robertle left
dogbert2_ timotimo: it's over the counter in Sweden as well. On the other hand I believe that you'd need a prescription in the States (and probably some other countries as well) 13:54
jnthn Oh, goodness, I see it... 13:55
The return value of !reduce ain't used 13:56
13:56 zakharyas joined
jnthn Now, after inlining, we can thus delete some `set` instructions that the return was rewritten into, and one more besides 13:57
A deopt annotation is somehow on one of the set instructions
13:57 p6bannerbot sets mode: +v zakharyas
jnthn Oh, but that's not the problem 13:58
13:58 robertle joined
jnthn A deopt annotation is also in the inliner on a decont instruction 13:58
13:59 p6bannerbot sets mode: +v robertle 14:22 Ven`` left
Geth MoarVM/persist-inline-deopt-info: 82974ce57c | (Jonathan Worthington)++ | src/spesh/manipulate.c
Correct annotation motion to not break uninlining

Moving of an annotation into an inline or onto a deopt all can cause problems when we come to uninline.		 14:42
MoarVM/persist-inline-deopt-info: 909d354ca2 | (Jonathan Worthington)++ | src/spesh/dead_ins_elimination.c
Allow dead instruction elimination in inlines

Previously we could not do this, since we lacked any sense of which values have to be preserved in order to not break deopt. Now that info is available, we can perform this inside of inlines too. This is most immediately useful when we consider instructions that produce a return value, which is the inlined into something that doesn't care for the return value. Such instructions can then simply be deleted.
jnthn This all seems to work quite nicely except...I exploded the profiler :( 14:48
hmm, that's interesting... 14:50
==8172== Invalid read of size 8
==8172== at 0x511196A: get_facts_direct (optimize.c:42)
==8172== by 0x51119FC: MVM_spesh_get_facts (optimize.c:54)
==8172== by 0x5105459: write_instructions (codegen.c:115)
==8172== by 0x51062AE: MVM_spesh_codegen (codegen.c:312)
==8172== by 0x5182F0E: add_instrumentation (instrument.c:239)
14:51 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, Ven`` joined 14:52 p6bannerbot sets mode: +v Ven``
timotimo i do sometimes already get "unable to fix up handlers" or whatever in some programs when trying to profile 14:54
and it's even worse, it feels like, when trying to use line coverage 14:55
jnthn It's a silly one this time, thankfully
There are no ->facts available when we're instrumenting 14:56
timotimo oh, OK
jnthn So looking at them when doing code-gen is just instant SEGV 14:57
14:57 MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
timotimo right 14:57
i didn't realize we'd ever try to do that :)
MasterDuke if there's a jit template for an op do we still need a lego jit implementation also? 14:59
timotimo usually yes
MasterDuke ok, thought so
timotimo imagine a block where the exprjit bails on some unrelated op, and then an op comes up that only has an expr jit implementation but no lego one
MasterDuke so atkey_u needs a lego jit implementation
right 15:00
Geth MoarVM/persist-inline-deopt-info: db65a28151 | (Jonathan Worthington)++ | src/spesh/codegen.c
Unbreak the profiler

And other such instrumentations. When we're doing these, we have no facts, and we don't need deopt info either. Since in this mode we now never push to the vector, it ends up never allocated, so we won't have a leak in this case either.
jnthn OK, that gets me clean for this branch
15:00 Ven`` left
timotimo we're in a post-fact world anyway 15:00
jnthn Which was mainly aimed at unblocking further pea work, but we get slightly better code quality in some other cases.
Lemme throw it at a large project or two before I merge. 15:01
oh lol, thought I'd caused a major perf regression, but it was just a debug build 15:02
timotimo ha, i've done that a few times in the past :) 15:03
MasterDuke huh, i see just a couple lines back in my terminal that i used MVM_JIT_LOG=j.log and it had some BAILs in it, and now when i rerun there aren't any 15:04
timotimo well, MVM_JIT_LOG doesn't exist any more 15:05
and the strings for bailing in the spesh log aren't as uniform any more :\
MasterDuke ah, but a log file is still created
looks like more templates are needed also 15:08
timotimo extend and truncate potentially?
coerce_ui and iu?
MasterDuke gist.github.com/MasterDuke17/37857...fa827a906f 15:09
when running some stripped down code from the .assuming is slow rakudo issue
Geth MoarVM/master: 7 commits pushed by (Jonathan Worthington)++ 15:11
jnthn There we go, merged :)
MasterDuke jnthn: does the unbreak the profiler commit only fix a break the branch introduced, or might it be a more general fix? 15:13
jnthn Only one the branch introduced
The code it exploded in was added in the branch 15:14
MasterDuke ah
jnthn (Regression introduced back in 0fef86cbe8)
Phew, the pea rebase was only very slightly conflicty 15:15
Geth MoarVM/pea: 32 commits pushed by (Jonathan Worthington)++, (Carl Masak)++
review: github.com/MoarVM/MoarVM/compare/9...0a0774adf6		 15:18
15:19 lucasb left
timotimo well, i'm glad to see that detour worked out so well :) 15:19
timotimo gets to change the algorithm by which flame graphs are "extracted" from the profiler database, yay 15:20
i'm thinking of making it "incremental", so that the frontend can receive the first 5 layers immediately, another 10 a second later etc 15:21
and as the user "zooms" in fetch more
jnthn Hm, interesting :) 15:24
timotimo i'll also want to put in something that stops descending when a branch is only like a few pixels wide - until the user selects something close to it that makes it wider 15:25
i'm hoping to make the code to get the data so fast that there's no reason to cache the data in the backend :)
MasterDuke i assume i should use MVM_JIT_RV_INT for _u ops? 15:29
jnthn I *think* at that level signed/unsigned isn't a think
*thing
timotimo probably 15:31
yeah
MasterDuke hm, there's no MVM_repr_at_key_u()
timotimo i don't think we have anything other than at_key_o at all 15:32
or do we have that and it's just a coerce on top of the at_key_o?
MasterDuke there's _i and _s and _n
timotimo oh, yup, i was wrong 15:33
maybe because our hashes can only store objects rather than any natives
japhb jnthn: Are you planning to bump nqp/rakudo to pick up your merged changes, or are you holding off for more? 15:35
jnthn japhb: I'm back to working in a branch now; I figure with MasterDuke++ looking at JIT additions there'll be a bump soon enough, so it can go in with those. 15:37
japhb Gotcha 15:39
MasterDuke arg! still getting a BAIL for atkey_u 15:42
timotimo forgot to add the case in the second place?
MasterDuke i don't think so 15:43
timotimo: gist.github.com/MasterDuke17/15882...f77607578f 15:44
timotimo looks correct 15:47
er 15:48
"op == op == ..."
that's probably the mistake
15:48 dogbert2_ left
MasterDuke timotimo++ 15:49
huh, but still the same behavior 15:51
timotimo Failed to open file /home/timo/perl6/install/share/perl6/repo.lock: No space left on device
in block <unit> at tools/build/install-core-dist.p6 line 28
d'oh
MasterDuke hm, i added an fprintf in MVM_repr_at_key_u and it's never getting hit 15:54
brrt: ping 16:02
timotimo: or any further fixes? 16:04
brrt MasterDuke: pong 16:07
MasterDuke brrt: have you seen my past couple comments? 16:08
brrt no
what's the problem 16:09
MasterDuke i'm attempting to add a lego jit implementation for atkey_u
brrt uhuh
MasterDuke since that what appears to be causing nqp::index to not get jitted
16:10 robertle left
MasterDuke gist.github.com/MasterDuke17/15882...f77607578f here's what i have so far, but there's no change in behavior 16:10
and then i added an fprintf in MVM_repr_at_key_u and it's never getting hit
fwiw, this is how i'm testing: perl6 -e '$_.Str.index(0.Str, 0) for 1 .. 1_000_000' 16:11
(and adding --profile ) 16:14
brrt uhuh 16:18
that doesn't look wrong, to me... 16:19
MasterDuke heh, don't know if that's a good thing or not
16:24 domidumont left
brrt well, it means, i can't see readily if it is broken 16:26
I can't really hep you, is what it means 16:27
MasterDuke heh 16:28
fwiw, when running that code MVM_repr_at_key_i and MVM_repr_at_key_u are never called, but MVM_repr_at_key_o is 423406 times 16:31
brrt yeah 16:39
because MVM_repr_at_key_u is for when you get an unsigned integer out of an object
MasterDuke huh, added an fprintf in atkey_u in interp.c and that isn't getting hit either
brrt E_THEORYWRONG
MasterDuke seems like it might be...so what's the way to tell for sure why index isn't getting jitted? 16:40
i see a single '# JIT: bailed completely' in the spesh log 16:44
brrt hmm, what's more arround it? 16:45
MasterDuke gist.github.com/MasterDuke17/b40d2...8153d59615 16:46
updated the gist 16:47
with what appears before the list of BBs
brrt: btw, is github.com/MoarVM/MoarVM/blob/mast...#L236-L240 still correct? 16:54
16:54 brrt left
MasterDuke afk for a while, but i'll backlog if anybody has a suggestion 17:02
17:14 patrickb joined 17:15 p6bannerbot sets mode: +v patrickb
nwc10 jnthn: ASAN build for origin/pea gets to Rakudo's tests 17:36
many fail, the two that I spot-checked fail at 17:37
==25646==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f2f4e32c5eb sp 0x7fffdcf69830 bp 0x7fffdcf698e0 T0)
#0 0x7f2f4e32c5ea in log_parameter src/spesh/log.c:94
#1 0x7f2f4e32cdc9 in MVM_spesh_log_entry src/spesh/log.c:131
without proceding pavement pizza
17:38 brrt joined 17:39 p6bannerbot sets mode: +v brrt
timotimo MasterDuke: even if a function never gets run, if a routine contains it somewhere, it'll still be able to bail out the jit 17:39
jnthn nwc10: Yeah, that's 'cus deopt situations involving PEA and inlining together weren't implemented yet :) 17:47
I think I finally have patches locally that do that 17:48
brrt oooh 17:50
jnthn Also relieved that the case I'm looking at is an aliasing one, and it gets it right, which means the alias tracking (e.g. when we `set` with an allocation we eliminated) is working right too.
The reason for such SEGVs, though, was because without it knowing to materialize some of the eliminated allocations, it put just left NULLed registers behind after deopt 17:53
s/put//
This stuff involves quite a bit of brane...
Maybe I should submit a talk about it at the German Perl Workshop so others can be tormented too... :P 17:54
brrt that'll show them
lizmat whee! 17:56
brrt (hmm, now we insert a (STORE of a (LOAD_NUM)) somehow :-( 17:58
Geth MoarVM/pea: 2e227fd8a1 | (Jonathan Worthington)++ | 3 files
Distribute deopt usages when inlining

If we have an invoke, then there might be some registers that have a deopt usage at that point. This implies that if we deopt, then we must ensure that the values in those registers are available. Clasically this has meant that we simply could not delete an instruction that writes to the register. However, in our PEA new world, we actually *do* delete ... (20 more lines)		 18:04
MoarVM/pea: ab6b143d54 | (Jonathan Worthington)++ | src/spesh/pea.c
Correct a thinko, remove an unused variable
 18:05
MoarVM/pea: 624a114916 | (Jonathan Worthington)++ | src/spesh/pea.c
Log target register of eliminated allocations

To make for slightly easier debugging.
jnthn That's now rather less explosive :) 18:06
18:10 domidumont joined 18:11 p6bannerbot sets mode: +v domidumont
jnthn Time for noms :) 18:17
patrickb Hi everyone! 18:22
brrt hi patrickb
patrickb I just learned that ld drops symbols from included libraries it doesn't need. 18:23
brrt it does
patrickb That basically kills the possibility for my runner program to utilise uv_exepath() from libuv through moar. 18:24
brrt hmmm
patrickb Including libuv in rakudo is definitely overkill. :-(
brrt maybe we can expose uv_getexecpath() as an op 'vmpath'
patrickb I don't need it in perl6 land 18:25
I need it in a small C program that links against libmoar
adding an OP would solve the problem, because then that function wouldn't be stripped. 18:26
But I'm not sure adding an op just to prevent stripping is the right approach :-P
I think the best thing to do is leaving moarvm alone and just use github.com/gpakosz/whereami directly. 18:32
brrt you can do that as well
(yay, I debugged a problem) 18:33
patrickb brrt: Thinking about it some more, do you think it'd be worth it to add that op to fix up $*EXECUTABLE? 18:41
brrt I don't see the immediate problem...
What I really think is; perl5 programmers have come to expect the luxury of $FindBin 18:42
we should have the same
lizmat fwiw, there *is* a Perl 6 version of FIndBin 18:43
patrickb Well it just returns the --exec-path passed to moar via the script runner we currently have 18:44
(that might not be 100% acurate, but roughly).
And that only works stable at the moment, because we have the path hard coded into the runner... :-/ 18:45
$*EXECUTABLE returns the path to perl6, not the script being run. 18:46
Geth MoarVM/jit-expr-float: ae077858fa | (Bart Wiegmans)++ | 6 files
[JIT] More rigorous type checking

  - actually implement a sensible type check
  - check type of expression return value with output operand, if any
  - check type of IF operands
On the other hand, I'm not convinced we actually want a STORE_NUM operator.		 18:51
brrt ok, that's it for me today
18:52 brrt left 19:20 patrickb left 19:22 patrickb joined, p6bannerbot sets mode: +v patrickb 19:49 cygx joined 19:50 p6bannerbot sets mode: +v cygx
cygx patrickb: the moarvm DLL is linked against libuv, so you should be able to create a small MVM_get_path() function that delegates to uv_getexecpath() and then call that... 19:52
patrickb But is that a smart thing to do? It's basically adding stuff to the moar API... 19:53
MasterDuke timotimo: did you look at the spesh log excerpt i gisted? can you see anything helpful there?
cygx shrugs 19:55
if it solves a legitimate problem, I wouldn't let purity be the enemy of pragmatism... 19:56
20:01 zakharyas left
patrickb cygx: Thanks for the heads up! 20:04
jnthn: Any objections to me adding a MVM_exepath() to moarvm?
moarvm API that is 20:05
20:05 robertle joined 20:06 p6bannerbot sets mode: +v robertle
nwc10 jnthn: building with ASAN. For some reason t/02-rakudo/repl.t is *very* hungry for CPU 20:14
not sure if this is bad luck, or something wierd and new.
it's not failing. just slow. so slow it might take another hour
MasterDuke ok, i added ins->info->name to the "JIT: bailed completely" error, and it now says it's ctxouter 20:20
which has no lego jit implementation or template
20:21 domidumont left
MasterDuke but istr that is one of the problematic ones and a naive jit implementation won't work? 20:21
20:31 Ven`` joined 20:32 p6bannerbot sets mode: +v Ven``
MasterDuke huh, i cherry-picked github.com/MoarVM/MoarVM/commit/f1...5327100cff and now there aren't any 'bailed completely' in the spesh log, but a profile still shows index as unjitted 20:37
ok, so the 'after' part of the spesh log for index has this in it: `# BAIL: Unexpected opcode in invoke sequence: <speshresolve>` 20:42
maybe i'm still barking up the wrong tree, but is there something that can be done about that? 20:43
21:00 Ven`` left, bartolin joined 21:01 p6bannerbot sets mode: +v bartolin
Geth MoarVM: MasterDuke17++ created pull request #1031:
Add op name to jit "bailed completely" error		 21:28
21:40 cygx left
lizmat jnthn: on every Parameter I see in signatures, I see the SIG_ELEM_MULTI_INVOCANT bit set 21:40
jnthn: what is the way to *not* have that set ? 21:41
timotimo MasterDuke: you mean the bail of ctxouter?
MasterDuke timotimo: no, it's not bailing on that any more since i cherry-picked github.com/MoarVM/MoarVM/commit/f1...5327100cff 21:42
well, there's no template, but the other bail message is gone
it's the `Unexpected opcode in invoke sequence: <speshresolve>` that seems to be the problem now 21:43
timotimo well, i'm not sure why speshresolve wouldn't have been sp_'d
could be interesting to find out how it got past spesh
other than that, an implementation of speshresolve could be very similar to sp_speshresolve 21:44
MasterDuke timotimo: this? github.com/MoarVM/MoarVM/blob/mast...#L538-L546 21:46
21:46 patrickb left
timotimo oh 21:46
right, it's an invoke, and those are a bit special 21:47
i don't know how invokes work in the jit, tbh
MasterDuke yeah, i don't really understand what's happening there, or the speshresolve->sp_speshresolve conversion 21:48
timotimo: any logging i could put somewhere to find out why that conversion isn't happening? 21:50
timotimo there's a gdb script that can step-by-step the spesh process
"source ~/perl6/moarvm/tools/trace_spesh_optimizer.gdb" in the gdb console with a path that's appropriate for your system 21:51
then you have your breakpoint in MVM_spesh_candidate_add
and put "trace_spesh_optimize" in your gdb commandline
MasterDuke wow that's weird, what are all the git commands doing? 21:53
huh, now it's showing some diff
timotimo yeah :)
it abuses git to have a version history with comments 21:54
MasterDuke hm, how do i skip ahead to where it's doing 'index'?
timotimo oh, i should perhaps point out that the MVM_spesh_candidate_add should be for the code you're interested in, not just the first one you find 21:55
MasterDuke it looks like if i hit q in the diff and then ran trace_spesh_optimize again it would move on to the next thing 21:56
oh, now i need to continue in gdb it looks like
timotimo i usually have something like "condition" "p->sf->body.name->body.num_graphs == " and then the number of characters the frame i'm interested in has
that narrows it down a bunch
MasterDuke Bad breakpoint argument: 'p->sf->body.name->body.num_graphs == 5' 21:58
oh, can't i set a breakpoint on `char *c_name = MVM_string_utf8_encode_C_string(tc, p->sf->body.name);` where c_name eq 'index'? 21:59
timotimo only if you have spesh logging enabled 22:00
MasterDuke any reason not to do that? 22:01
timotimo you'll want to use $_streq(c_name, "index")
22:09 KDr2 left
MasterDuke ah ha, now i'm broken there 22:09
22:10 KDr2 joined, p6bannerbot sets mode: +v KDr2
MasterDuke huh, trace_spesh_optimize is paused after create mode 100644 speshdump.txt 22:11
oh, ctrl-c and now i see a diff 22:14
timotimo: what should i look for?
hm, think i did everything correctly, but i don't see that BAIL speshresolve thing in any of the diffs 22:21
huh, but it is in the spesh log 22:24
jnthn .tell patrickb No objections; I'd prefer that than to have things make an assumption that MoarVM is using libuv (there's no plans for it not to any time soon, but better to keep it as an impl detail) 22:39
yoleaux jnthn: I'll pass your message to patrickb.
jnthn lizmat: ;;
timotimo MasterDuke: bail happens after the spesh process is done, there is no entry for that in the spesh "trace" 22:43
you'll want to see where it goes past "speshresolve" and doesn't change it, or where it puts it in there
MasterDuke ok, i do see speshresolve in the "before" 22:44
what does "goes past" mean? 22:45
timotimo when it optimizes stuff before the speshresolve, and then after it 22:46
like, in the BB order
MasterDuke hmm, looks like the diff of the "going to optimize a bb" doesn't show which bb 22:47
timotimo oh? it's supposed to :(
MasterDuke well, sometimes it does (because the change was near enough the id line to be in the context) 22:48
timotimo you should be able to find the git dir in /tmp and git log it manually with a higher context parameter 22:49
MasterDuke would MVM_SPESH_BLOCKING=1 help make BB numbers the same across different runs? 22:55
timotimo not BB numbers, no. only the order of functions that get speshed gets more stable
MasterDuke huh, setting that got me: `===SORRY!=== Frame has no lexical with name '&reduce'` 22:56
timotimo huh, that's fun ?!? 22:57
MasterDuke that was just starting perl6-gdb-m, after i hit r in gdb i get: ===SORRY!=== Frame has no lexical with name '&infix:<(|)>'
if i don't use gdb i get the same error every time, though the thing it can't find changes 22:58
timotimo o_O
MasterDuke hm, might be that ctxout jit commit i cherry-picked 23:00
because it doesn't happen on a rakudo almost at HEAD, but with a vanilla MoarVM
huh, the BB info in spesh log i create while running the script doesn't seem to match up with what the script outputs 23:04
should it?
timotimo oh, i think it sometimes gets confused with inlines
at least i think so?
MasterDuke oh wait, maybe it does match (at least the "before") 23:05
huh, so i see `- sp_fastcreate r8(2), liti16(32), sslot(0)` from the BB that has the BAIL by the end, but i don't see where that got added, and it wasn't in the BB "before" 23:07
oh wait, later in the log i see it being added in place of `param_sn r8(2)` 23:08
timotimo: i just don't see speshresolve in the BB in the trace script output, even with context set to a very high number 23:15
could there have been some spesh stages added since you wrote the script? 23:16
timotimo hm, that's possible 23:18
if you want you can add to it
MasterDuke i just added ~40, but the script now seems to be paused after the first commit 23:32
it shouldn't matter what order they're in in the script, right? 23:34
timotimo shouldn't, no 23:39
MasterDuke oh, that time it went 23:40
well, seems to have recorded more, but still not what i want...arg 23:41
i just added all the optimize_* in src/spesh/optimize.c, but i guess it's some other function i need to add 23:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!