github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
brrt \o 08:27
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
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
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
lizmat wonder if this could be useful for Moar: www.viva64.com/en/b/0583/ 10:58
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
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
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
jnthn Finally, my escape analyzer manages its first useful optimization :) 16:41
timotimo \o/
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?
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
Kaiepi making an asyncsocket op and passing the socket it creates to asyncconnect/asynclisten ops seems to be going smoothly so far 20:27
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
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
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 :)

Powered by Cro and the Raku® Programming Language.

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

Thank you!