github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:07 telexhJ joined, telexhJ left 00:20 lizmat left 00:26 lizmat joined, p6bannerbot sets mode: +v lizmat 03:55 conekinsUL joined, conekinsUL left 04:44 robertle_ joined 04:45 p6bannerbot sets mode: +v robertle_ 04:52 avar left, robertle left 04:57 avar joined, niven.freenode.net sets mode: +v avar, p6bannerbot sets mode: +v avar 05:24 domidumont joined 05:25 p6bannerbot sets mode: +v domidumont 05:31 domidumont left 05:43 AlexDaniel left 05:56 fake_space_whale left 06:06 domidumont joined 06:07 p6bannerbot sets mode: +v domidumont 06:45 obadzzR joined, obadzzR left, benchable6 left 06:48 arecaceaegX joined, arecaceaegX left 06:56 Connorhd joined 06:57 p6bannerbot sets mode: +v Connorhd 07:04 Connorhd left 07:36 benchable6 joined 07:37 p6bannerbot sets mode: +v benchable6 07:44 AlexDaniel joined 07:45 p6bannerbot sets mode: +v AlexDaniel
AlexDaniel squashable6: status 07:46
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in ≈2 hours (2018-10-06 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
07:48 reportable6 left, shareable6 left, committable6 left, reportable6 joined, bisectable6 joined, shareable6 joined, undersightable6 left, committable6 joined, evalable6 left, undersightable6 joined, releasable6 joined, evalable6 joined 07:49 p6bannerbot sets mode: +v reportable6, p6bannerbot sets mode: +v bisectable6, p6bannerbot sets mode: +v shareable6, p6bannerbot sets mode: +v committable6, p6bannerbot sets mode: +v undersightable6, p6bannerbot sets mode: +v releasable6, p6bannerbot sets mode: +v evalable6 07:59 robertle_ left 08:01 robertle joined 08:02 p6bannerbot sets mode: +v robertle 08:15 robertle left 08:21 robertle joined, p6bannerbot sets mode: +v robertle 08:27 brrt joined, p6bannerbot sets mode: +v brrt
brrt \o 08:27
08:28 robertle left
timotimo o/ 08:28
brrt ohai timotimo
I've figured out what we need to figure out
timotimo oh, for the annotation position problem?
brrt long story short; INLINE_END annotations indeed move to the succeeding instruction
when deleted
.... I think that's wrong 08:29
matter of fact, I will say this. I think the inline_start and inline_end annotation should probably go on basic blocks, not on instructions
timotimo so we never fuse bbs around inlines? 08:30
we used to have "is_inlined" on BB
brrt oh, hmmm
that's not desirable either
maybe
maybe we can 'color' instructions with their inline source
and make a map of contiguous inline bounds when we emit the code 08:31
meh, that sucks as well :-) 08:33
timotimo yeah, it'll be weird 08:34
especially when we insert more instructions while optimizing
and depending on whether the part of code in question is just changing an ins's info to a different ops's one
or creating a new ins struct
jnthn I'm pretty sure inline end marks the instruction *after* the last one of the inlined code 08:36
That can be important, if we rewrite the return, optimize it entirely away, then the last thing is an `invoke` 08:37
08:37 robertle joined 08:38 p6bannerbot sets mode: +v robertle
brrt jnthn: no, it really doesn't. 08:45
src/spesh/inline.c 1174 inserts the INLINE_END on the last_ins of the last_inlinee_bb 08:46
so it is in 'inclusive' annotation, and I process it post-instruction, which is the source of my bug, because I don't process annotations on the invoke sequence in the legacy JIT :-) 08:47
08:48 MasterDuke left 08:51 dalek left
brrt and actually, I'm not really sure I need to process the invoke sequence as a block 08:51
jnthn brrt: Yes, but the last instruction of last_inlinee_bb is just the rewritten `return` instruction, which can never deopt, throw, etc. 08:59
I should probbly have said "the last *interesting* instruction" :) 09:00
brrt well, if that instruction is removed, the annotation now ends up beyond that 09:03
in my case, prepargs
I'll upload the offending spesh log :-)
jnthn Yes, I know; I had to fix this a while back :) 09:04
brrt gist.github.com/bdw/172c333ca2d8a6...18bd784ede 09:05
jnthn Because it wasn't moving the annotation far enough
brrt hmmm
jnthn Or the wrong way, or whatever
And then we had a deopt bug thanks to it
brrt well, this would give you a deopt bug in the wrong case as well, because the JIT now drops them when they're in the invoke sequence
and I kind of feel like this is dangerous? what if the first instruction of the next block was a dynamic lexical lookup? 09:06
it's going to think it is coming from the (wrong) inline
gist.github.com/bdw/172c333ca2d8a6...-txt-L8168 here, to be exact 09:07
anyway, I can fix this from the JITs end. I just think this is a potential bug, is all 09:12
jnthn Hmm, potentially
09:27 brrt left 09:42 AlexDaniel left 10:53 brrt joined 10:54 p6bannerbot sets mode: +v brrt 10:55 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
lizmat wonder if this could be useful for Moar: www.viva64.com/en/b/0583/ 10:58
11:14 brrt left 11:44 brrt joined 11:45 p6bannerbot sets mode: +v brrt 12:14 brrt left 12:15 brrt joined, p6bannerbot sets mode: +v brrt 12:23 zebrahKn joined, zebrahKn left 12:55 viceroyyM joined, viceroyyM left
jnthn Aww, no Geth :) 13:00
timotimo oh, huh
it isn't supposed to not be here
jnthn ah, ping timeout some hours back 13:01
timotimo pea debug logging, i see
jnthn Yeah...well, basically it's about useless without handling branches :) 13:12
Loops will come much later
But branches...can do :) 13:13
timotimo even more reason to build tracing spesh ;)
jnthn haha
No, traces end up with side traces and then it's still as hard :)
timotimo true
13:17 brrt left
jnthn Hm, the throwcat opt screws the CFG 13:36
Such that computing rpo on it afterwards fails
ah, it doesn't fix the preds properly 13:40
Figured it out. Now I can haz RPO. 13:51
dogbert2 does that mean that you're ready to merge stuff? 13:59
14:01 agaidaep joined, agaidaep left
jnthn haha...no, far from it :) 14:19
dogbert2 it was worth a shot :) 14:27
jnthn Yeah, escape analysis is fairly involved :) 14:28
dogbert2 but I guess that the rewards might be worth it
jnthn Oh yes, should be :)
The EA goes by a two-pass algorithm, first figuring out what we can transform, and then applying the transforms. Seems that to handle guards well, phase 1 will need some "shadow facts" or something 14:35
So we can see they could be eliminated 14:36
Hmm
14:39 msonntagDL joined, msonntagDL left 15:28 fake_space_whale joined 15:29 domidumont left, p6bannerbot sets mode: +v fake_space_whale 16:00 emerson left 16:01 emerson joined, p6bannerbot sets mode: +v emerson 16:26 TimToady left, TimToady joined, barjavel.freenode.net sets mode: +v TimToady, p6bannerbot sets mode: +v TimToady 16:31 patrickb joined 16:32 p6bannerbot sets mode: +v patrickb 16:36 robertle left 16:39 ggoebel joined 16:40 p6bannerbot sets mode: +v ggoebel
jnthn Finally, my escape analyzer manages its first useful optimization :) 16:41
timotimo \o/
16:42 domidumont joined 16:43 p6bannerbot sets mode: +v domidumont
timotimo Zoffix, can you restart Geth? 16:43
Kaiepi so for the IO::Socket::Async native-descriptor pullreqs, i'm thinking of adding an extra op to initialize a socket for listening instead of doing it all at once in .listen so that the native socket is available to use to get the native descriptor as soon as its made, rather than after tapping it 16:45
thoughts?
timotimo at first glance that sounds useful
jnthn github.com/MoarVM/MoarVM/commit/5b...f41ecc8ff9 16:56
That was hard work for a Friday afternoon :)
jnthn goes for some dinner/rest 16:59
timotimo nice 17:00
at one point we'll also get at the hash's entries with just "set", too?
17:44 goran-mahovlic_ joined, p6bannerbot sets mode: +v goran-mahovlic_ 17:46 goran-mahovlic_ left 17:52 Hobby_boykm joined, Hobby_boykm left 18:05 Kaiepi left 18:07 Kaiepi joined 18:08 p6bannerbot sets mode: +v Kaiepi 18:51 lipvigHE joined, lipvigHE left
AlexDaniel timotimo: you're asking Zoffix to restart Geth? :) Wasn't it you who had an ability to restart hack when it hangs? 18:59
timotimo oh, somehow i forgot that gets runs off of hack 19:00
AlexDaniel :) 19:01
19:02 synopsebot left, SourceBaby_ left, p6lert left, dalek joined, Geth joined, p6lert joined, synopsebot joined 19:03 p6bannerbot sets mode: +v dalek, p6bannerbot sets mode: +v Geth, p6bannerbot sets mode: +v p6lert, p6bannerbot sets mode: +v synopsebot 19:23 lizmat left 19:24 domidumont left 19:27 lizmat joined, p6bannerbot sets mode: +v lizmat 19:33 OslegYX joined, OslegYX left 20:00 Kaiepi left 20:01 Kaiepi joined 20:02 p6bannerbot sets mode: +v Kaiepi 20:22 QizzyFl joined, QizzyFl left
Kaiepi making an asyncsocket op and passing the socket it creates to asyncconnect/asynclisten ops seems to be going smoothly so far 20:27
20:54 teuscg joined, teuscg left
Kaiepi tools/update_ops isn't updating the oplist when i run it 21:18
jnthn ? 21:22
src/core/oplist is its source data
You update that, run the script, and add an impl to src/core/interp.c 21:23
It'll update the various op metadata files
(which are generated)
Kaiepi oh, ok 21:38
thanks
Unhandled exception: Hash keys must be concrete strings 21:40
i'll try reinstalling moar/nqp/rakudo and running it again 21:43
jnthn You'll need to recompile the extops in Rakudo after such a change (rebuilding Rakudo entirely will do that for sure) 21:46
Kaiepi how do i update src/vm/moar/stage0/MASTOps.moarvm and src/vm/moar/stage0/QAST.moarvm in nqp? 21:55
jnthn Do you need to?
But if yes, `make bootstrap-files` should do it
(Only update these if needed, since it increases repository size) 21:56
22:20 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 22:22 patrickb left
Kaiepi Unhandled exception: Bytecode validation error at offset 20, instruction 5: 22:26
operand type 56 does not match register type 32
at <unknown>:1 (src/vm/moar/stage0/ModuleLoader.moarvm:<dependencies+deserialize>)
from <unknown>:1 (src/vm/moar/stage0/nqp.moarvm:<dependencies+deserialize>)
how can i debug this?
jnthn First of all, did you follow the instructions at the top of oplist for where to add the new op? 22:30
It's a weird failure mode, but inserting it in the wrong place (e.g. not after all existing non-spesh ops) could cause something like this 22:31
Kaiepi ohh 22:35
that could be why
22:35 Ven`` joined 22:36 p6bannerbot sets mode: +v Ven``, Ven`` left
jnthn :)Nárožní 22:37
oops
*:)
Kaiepi that seems to have fixed the problem 22:40
thanks
i was putting asyncsocket above asyncconnect/asynclisten, instead of before the spesh ops
jnthn 2ah 22:43
Yeah, order matters
Bah, what's with my typing tonight :)