japhb_ Dangit, I missed jnthn. :-( 00:30
Well, in any case ...
.tell jnthn I was referring to problems with the output of github.com/japhb/perl6-bench/blob/...orest-fire 00:31
brrt hey, i think i've found the source of the bug in moar-jit 06:58
it's the combination with inline
i.e - inline 'inlines' a frame that has a instruction of sp_enter_jit 07:00
sp_enter_jit looks as the (now changed) frame and decides there isn't any jitcode
sp_enter_jit freaks out :-)
(because the bigger frame, even if fully compatible with jit otherwise, cannot compile sp_enter_jit yet) 07:01
brrt tl;dr - i need some form of register for the jitcode and refer to that in the enter_jit opcode, otherwise inlining breaks jit 07:25
brrt the only question left is 07:29
what register
locally (hanging of the StaticFrame) or globally (hanging of the CompUnit or even the MVMInstance)? 07:30
FROGGS is enter_jit coupled to any of these three? 07:31
brrt ehm, no 07:33
it used to be that the jit compiler compiled a whole frame or nothing
the inliner obviously changes that, as i've seen 07:34
the jitcode /used/ to hang off of the spesh candidate of the static frame
or, does now, actually
the register is just there to answer the question 'what jitcode do you want to call?' 07:35
i think the core of it is this: if i register jit code globally, then during inlining, i don't need to change anything (yay), because the sp_enter_jit can still refer to the same entry 07:38
if i register jit code on the static frame - in any sense, either on the spesh candidate or directly - then i need to take care of that in inlining
i.e. merge the registers of inlined frames
and update the sp_ente_jit opcodes to refer to the right register entries 07:39
i actually think that is the better option, but i can't readily explain why :-)
FROGGS hmmm, well, jnthn's opinion will shed light on this then :o) 07:43
brrt he wouldn't be here today, would he? 07:50
FROGGS I have no idea 07:51
brrt ok, i know why a local register is better
basically, it allows to keep the index small 07:52
timotimo It seems like it's a travel day for jnthn 07:53
brrt is off for a few hours 08:59
dalek arVM/moar-jit: 22773f2 | jnthn++ | src/spesh/args.c:
Don't refuse to spesh if we've a slurpy positional
20:02
MoarVM/moar-jit: dd80dbf | (Timo Paulssen)++ | src/spesh/optimize.c:
MoarVM/moar-jit: put in a missing break
[Coke] we lost the review line there. 20:06
brrt that should've been a merge line, though 20:17
timotimo yes, those are mostly old-ish commits 20:40
dalek arVM: bc1bbc3 | Carlin++ | src/io/fileops.c:
Change default mode to 0x01FF

0x0FFF is 7777, not 0777
21:33
arVM: 8309dc2 | Carlin++ | src/io/syncfile.c:
Change default mode to 0x01FF
arVM: 5cdc366 | Carlin++ | src/io/ (2 files):
make default file mode 0644
MoarVM: f418844 | (Tobias Leich)++ | src/io/ (2 files):
MoarVM: Merge pull request #105 from carbin/master
MoarVM:
pmichaud regarding pull request / issue #105 in MoarVM, I think that file permissions in C programs should be specified as 0666... letting the umask setting take care of turning off group/other write permissions as appropriate. 22:13
I left a similar comment in the ticket.
jnthn +1, please somebody make it as pmichaud++ said 22:49
.tell brrt spesh for inlining needs to have access to the specialized bytecode; I suggest the jitcode is hung off just the ->effective_bytecode of the frame, but the bytecode slot of spesh_cand is left as it is (I'm assuming since the bug exists, it's being hung off spesh_cand). 22:51
Thta is, hvae MVM_spesh_invoke make the "enter jitcode" decision.
uh, MVM_frame_invoke
And thus the inliner still finds the bytecode itself. 22:52
sleep &