Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-06-08

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:17 dalek MoarVM: 81dabfb | timotimo++ | src/jit/emit_x64.dasc:
00:17 dalek MoarVM: why not have inf and neginf in addition to nan?
00:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/81dabfb5fb
00:17 dalek MoarVM: c2b33d0 | timotimo++ | src/jit/ (2 files):
00:17 dalek MoarVM: jit MVM_OP_exception (gets "current" exception object)
00:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c2b33d03b3
00:17 dalek MoarVM: af93de0 | timotimo++ | src/jit/ (2 files):
00:17 dalek MoarVM: jit sp_get_[inso]
00:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/af93de0a21
00:17 dalek MoarVM: c6b887a | timotimo++ | src/spesh/optimize.c:
00:17 dalek MoarVM: this is how we could optimize getex(category|message|payload)
00:17 dalek MoarVM:
00:42 dalek MoarVM: 34c7112 | timotimo++ | src/spesh/dump.c:
00:42 dalek MoarVM: fill registers and BBs with spaces so they align everywhere
00:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/34c7112d1b
00:43 timotimo not mentioned: pad the RHS of op names up to ~15 characters
00:43 timotimo (longer op names do exist, but are quite rare)
03:27 nwc10 joined #moarvm
06:15 FROGGS joined #moarvm
07:14 nwc10 good *, #moarvm
07:45 Ven joined #moarvm
07:50 jnthn moarning o/
07:50 nwc10 gr \o an
07:57 FROGGS o\oh deer
07:57 brrt joined #moarvm
08:02 brrt \o
08:08 jnthn o/ brrt
08:08 jnthn And FROGGS
08:13 jnthn nwc10: Gonna apply http://paste.scsys.co.uk/486642
08:13 nwc10 cool. I didn't bake a patch because I wasn't sure what the commit message should be
08:13 nwc10 heck, or even if it was the right fix
08:14 jnthn grmbl, it doesn't apply
08:15 jnthn Also now I look more closely at the patch, something is odd
08:16 jnthn Yeah :S
08:17 jnthn Now I look at it more in context I see your hesitation.
08:18 jnthn Assigning a union to a variable on the stack then back to another storage slot of the same union type should not have endian issues
08:19 nwc10 OK, I didn't notice that part
08:19 jnthn Well, taken together the lines are:
08:19 jnthn MVMSpeshOperand category = ins->operands[1];
08:19 jnthn ins->operands[2]         = category;
08:20 nwc10 it was mostly "I hit it with hammers and it seemed to work", and "fixes symptoms" without understanding why is not a valid reason to say "it's correct"
08:20 jnthn Well, just from a C language perspective, I think this can't be the right fix.
08:21 jnthn I can't believe a C compiler would mis-compile assignment of a union type...
08:21 nwc10 OK. I can't help you with *thinking* here, as I'm deep in some work code
08:21 nwc10 but I can probably apply better fixes and report back on tests, pretty fast
08:23 jnthn I fear it's going to take a bit of hunting :(
08:24 * jnthn will put it aside for the moment, to work on the nasty exception/inlining bug he was planning to tackle...
08:24 nwc10 yes, good plan
08:26 brrt oh, waitaminute about that patch
08:27 brrt bindexcategory tries to make a sp_bind_i, and category is uint32
08:27 brrt sp_bind_i writes a int64
08:27 brrt ergo, that spesh overwrites the return_after_unwind flag
08:28 jnthn brrt: oooooh
08:28 brrt we should probably not just spesh struct accesses to sp_(bind|get)_[inso]
08:28 jnthn No
08:28 brrt unless we also deal with the struct sizes
08:28 brrt eh
08:28 jnthn Correct
08:28 brrt field sizes
08:29 jnthn In fact we should probably leave the op as is for interpretation, and JIT it to a field access
08:29 * brrt nods
08:30 brrt anyway, we didn't implement them until justnow. maybe we should just remove them at all
08:30 brrt JIT can deal with them in another way
08:30 brrt add a access node
08:30 brrt or something like that
08:30 brrt (that's a plan anyway :-))
08:31 brrt for 64 bit things, payload and message can be taken safely
08:31 brrt for 32 bit platforms, that won't even work
08:32 jnthn But those are object/string typed, and sp_bind_o writes a pointer size, so those are ok?
08:32 zakharyas joined #moarvm
08:33 brrt hmm... letsee, yes you're correct
08:33 brrt they're ok
08:39 brrt ok, with that said, we only need to add an integer field size argument to sp_get_i and sp_bind_i. and that'd fix it?
08:41 jnthn Well, I'd add sp_get_i32 and sp_bind_i32
08:43 jnthn The exception/inlining bug is...tricky. Basically, we only consider one address when looking for a handler.
08:43 jnthn Meaning if we're in inlined code we don't search the outer frame.
08:43 jnthn Er, the inlining frame.
08:44 jnthn Trying to walk the inline chain is going to be (a) a bit fragile since it's deopt without the deopt, and (b) need a solution for the JIT too
08:44 jnthn Seems that we could just poke extra entries into the handlers table, however
08:45 jnthn Meaning it's still a simple linear scan
08:45 brrt wait, i'm not sure i comprehend fully
08:45 brrt but
08:46 brrt i like that suggestion by the simple heuristic of 'make data work not algorithms'
08:46 jnthn *nod*
08:46 brrt and as long as you correctly add spesh annotations the JIT *should* pick them up too
08:46 brrt but its been tricky testing them
08:46 jnthn I don't think I'd add any new annotations even
08:47 jnthn oh, maybe...
08:47 * jnthn looks into what would be the simplest way to do it
08:48 brrt well, i kind of need annotations in correct places in order to set the jit label markers
08:49 jnthn *nod*
08:50 brrt did you see the indirect-jump-to-reentry-label-hack by the way? i'm awefully proud of it's hackiness :-)
08:54 jnthn ex->body.jit_resume_label = tc->cur_frame->jit_entry_label; ? :)
09:11 brrt yes, that one
09:11 brrt also the
09:11 brrt jmp FRAME->jit_entry_label
09:11 brrt which is initialized to just-after if nothing was thrown, and to the correct resumption point otherwise
10:27 Ven joined #moarvm
10:34 jnthn Well, my patch fixes the bug and survives make and make test of NQP and Rakudo
10:34 * jnthn spectests it
10:52 jnthn Darn, close. One test file shows up problems.
10:54 masak that's the most interesting kind of situation :)
10:54 masak "the almost-fix"
10:54 jnthn Well, got one theory about what it may be.
10:55 jnthn nope :(
11:00 jnthn Wow, with the JIT disabled the same test file does a SEGV rather than a fail
11:13 Ven joined #moarvm
11:19 dalek MoarVM/inlining-exception-fix: 7c8efa8 | jnthn++ | src/spesh/inline.c:
11:19 dalek MoarVM/inlining-exception-fix: Factor out resizing of handlers table.
11:19 dalek MoarVM/inlining-exception-fix: review: https://github.com/MoarVM/MoarVM/commit/7c8efa84f0
11:19 dalek MoarVM/inlining-exception-fix: e648c9d | jnthn++ | src/spesh/ (2 files):
11:19 dalek MoarVM/inlining-exception-fix: Account for inliner's handlers when inlining.
11:19 dalek MoarVM/inlining-exception-fix:
11:19 dalek MoarVM/inlining-exception-fix: We do this by adding extra entries to the hnadlers table that cover an
11:19 dalek MoarVM/inlining-exception-fix: entire inlinee and go to the handler in the inliner. This means we can
11:19 dalek MoarVM/inlining-exception-fix: still find applicable handlers through a linear scan, so the handler
11:19 dalek MoarVM/inlining-exception-fix: lookup code needs no changes and need not become more complex.
11:19 dalek MoarVM/inlining-exception-fix: review: https://github.com/MoarVM/MoarVM/commit/e648c9dcde
11:20 jnthn nwc10: If you have time to run ^ under ASAN, especially t/spec/S32-exceptions/misc.rakudo.moar, that's be interesting.
11:28 jnthn lunch &
12:02 nwc10 jnthn: in setting
12:23 nwc10 # Looks like you failed 6 tests of 304
12:24 nwc10 no ASAN barfage
12:27 nwc10 http://paste.scsys.co.uk/487298
12:29 nwc10 MoarVM on origin/master passes all
12:29 nwc10 (well, TODOs are TODO)
12:29 nwc10 everything else was fine with ASAN
12:46 zakharyas joined #moarvm
13:33 Ven joined #moarvm
13:40 TimToady joined #moarvm
14:16 jnthn nwc10: OK, thanks for trying
14:20 * jnthn tries to figure out what on earth is going on with those six tests
14:21 nwc10 afk for 2 or 3 hours
14:21 nwc10 &
14:45 Ven joined #moarvm
14:45 jnthn yowser, it actually explodes inside of Perl6::Optimizer while doing the EVAL of the code its testing to see if it throws an exception.
14:48 FROGGS "yay"
15:14 lizmat joined #moarvm
15:45 Ven joined #moarvm
16:10 Ven joined #moarvm
16:45 jnthn Darn, this is a really tricky bug to find :/
16:59 Ven joined #moarvm
16:59 nwc10 step away from the computer for a bit?
17:03 jnthn Yeah, was just thinking about going shopping for some dinner... :)
17:03 jnthn Just discovered that the bug isn't at all the one I thought it was
17:13 * jnthn taeks a break
17:23 timotimo :o
17:23 timotimo i don't really know what bug you're hunting right now
17:24 timotimo but i'm still in awe
17:40 timotimo also ... ouch for the exception methods
17:41 timotimo i wonder if we could do much better at optimizing inlined things like our auto-generated accessor methods
17:41 Ven joined #moarvm
17:42 timotimo since the name of the attribute it accesses is closed over, and when we inline we inline a particular version of the closure (right?) we could have the values as a "known value" fact ... perhaps?
17:42 timotimo i notice i really don't know much about how our closures work
17:46 FROGGS joined #moarvm
18:41 brrt joined #moarvm
18:42 brrt jnthn: i probably don't have to ask if you've tested both with and without JIT
18:52 jnthn brrt: Yeah, it's independent of that
18:54 vendethiel joined #moarvm
18:54 brrt hmm. not sure if i'm really happy about that
18:54 brrt seems like a difficult bug :-(
18:55 brrt fwiw, os x gave me a clean spectest this morning
18:55 jnthn Especially since it cropped up as a result of fixing another tricky bug.
18:56 brrt hmmpf :-) vm's are hard
19:07 timotimo VMS is also hard, i hear
19:08 timotimo i should build a commit that turns off speshing for the getex* and bindex* ops
19:08 timotimo or completely throws out
19:08 timotimo right?
19:09 brrt probably, yes
19:09 brrt well, actually
19:09 brrt n, s, and o are ok
19:10 brrt you can make a sp_bind_i(8|16|32|64)
19:10 brrt or if you like
19:11 brrt sp_(bind|get)_[bwdq] ;-)
19:13 brrt aaactually, if you'd go that route, why not sp_(bind|get)_[bdwqpn]
19:13 brrt byte word doubleword quadword pointer number
19:14 brrt that'd cover all our needs, i'd think
19:14 brrt you don't have to do that though, because i'll be replicating the work soon enough
19:18 timotimo :S
19:18 timotimo fair enough
19:19 brrt well.. you can if you wish :-) there might well be cases in which it's worth it (repr accesses maybe)
19:44 lizmat joined #moarvm
19:52 jnthn cool, a thunderstorm :)
19:53 nwc10 roof testing?
19:53 jnthn Well, there's two stories worth of apartments between me and the roof, so if I find out about a test fail, it's a pretty epic one :)
19:54 nwc10 internal rain more likely (ie failed plumbing above)
19:54 jnthn Aye. Fingers crossed not though...this building seems well kept. :)
20:37 zakharyas joined #moarvm
21:02 brrt joined #moarvm
21:03 timotimo or flood via staircase
21:03 timotimo i'm a bit late to the topic, it seems
21:34 lizmat joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary