Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-06-11

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

All times shown according to UTC.

Time Nick Message
00:28 woosley joined #moarvm
01:22 FROGGS_ joined #moarvm
01:29 woosley left #moarvm
01:29 woosley joined #moarvm
05:38 brrt joined #moarvm
05:39 brrt .tell timotimo that only a really simple frame would be compiled, but spesh /should/ try to compile a frame that is invoked enough times
05:39 brrt that compiled function might well be wrong, i.e. there may be things that i've overseen
05:43 timotimo oh, neato
05:44 timotimo will your next blog post have examples of super simple frames that can already be compiled and maybe the resulting assembly?
05:46 brrt i hope so, yes
05:47 brrt i'm preparing how to make that super simple compiled frame :-) using MAST directly
05:47 timotimo i recall that part
05:47 timotimo sounds good :)
05:48 timotimo am i understanding correctly that you're basically taking ops that are little more than 1) get arguments, 2) invoke a C function, 3) set result register?
05:48 timotimo and turning them into direct access to the work space and an invoke directly to the C function?
05:51 brrt yes, its a little more than that already, but that is the gist of it
05:51 brrt calling a c function was quite a big deal so i worked quite a bit on it
05:51 brrt but i'm off for now, have to get bread for breakfast
05:52 timotimo OK :)
06:39 brrt joined #moarvm
06:46 zakharyas joined #moarvm
07:01 FROGGS joined #moarvm
07:09 oetiker joined #moarvm
07:24 oetiker_ joined #moarvm
07:35 nwc10 jnthn: (Un)success - ba6b4e37f8d99 breaks NQP -- backtrace from valgrind: http://paste.scsys.co.uk/392691
07:36 nwc10 ASAN colo(u)rfully unhappy too
07:36 oetiker joined #moarvm
07:42 nwc10 jnthn: OK, that ASAN explosion is (somewhat) late. Previous MoarVM on origin/inline will spectest under ASAN, but a regular debugging build with SEGV in the NQP build
07:42 nwc10 the cause of the SEGV appears to be strongly related to the *first* error in the valgrind report:
07:42 nwc10 ==26472== Conditional jump or move depends on uninitialised value(s)
07:42 nwc10 ==26472==    at 0x4FE6363: build_cfg (graph.c:325)
07:42 nwc10 so might be 2 bugs, or the ASAN failure might be the first bug finally causing an unhappy code path to be taken
08:06 jnthn nwc10: And this exists on HEAD also?
08:07 jnthn The 325 one is odd...
08:07 jnthn for (i = 0; i < g->num_inlines; i++) {
08:08 jnthn The spesh graph is calloc'd
08:09 jnthn (that's what's in g)
08:10 jnthn Ah...
08:10 nwc10 the undefined behaviour appears to be introduced by 54d3380fe92910f1845b358219dc5f2ba03d4137
08:10 nwc10 Start building inline extents table.
08:10 nwc10 clean build with 42fee8647314e83a326484a7b5d43fb478bf412d
08:11 jnthn I think the value ->num_inlines was initialized with was uninitialized
08:11 nwc10 now running valgrind having found a clean build
08:16 nwc10 have run 3 previously failing build commands with valgrind at 42fee8647314e83a326484a7b5d43fb478bf412d
08:16 nwc10 all happy.
08:16 dalek MoarVM/inline: 2c81704 | jnthn++ | src/spesh/candidate.c:
08:16 dalek MoarVM/inline: Ensure we don't read junk memory in a candidate.
08:16 dalek MoarVM/inline:
08:16 dalek MoarVM/inline: nwc10++ for reporting the Valgrind/ASAN error that was probably caused
08:16 dalek MoarVM/inline: by this.
08:16 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/2c81704591
08:17 nwc10 so I think that 54d3380fe92910f1845b358219dc5f2ba03d4137 is the culprit for the undefined behaviour
08:18 nwc10 OK, I've cherry picked that one onto 54d3380fe92910f1845b3 and it hasn't blown up yet
08:18 jnthn ok
08:18 jnthn bbi10
08:18 nwc10 will run that to completion, then try (new) origin/inline HEAD
08:19 jnthn thanks!
08:19 nwc10 take your time - I think it will take about 20 minutes
08:19 FROGGS nwc10++
08:34 brrt joined #moarvm
08:38 * jnthn back
08:38 jnthn morning, brrt
08:38 brrt hey, jnthn
08:38 brrt i've heard from mike pall wrt dynamic registers, i'll forward it to you
08:38 jnthn k
08:41 brrt how's things :-)
08:47 jnthn brrt: That's a helpful response. :)
08:47 brrt indeed it is :-)
08:47 jnthn And means that dynasm isn't going to be a dead end. :)
08:47 FROGGS can I see it?
08:47 jnthn (e.g. we can go further with it once we've got the simple thing working)
08:48 jnthn brrt: Things are fine, just doing the day's first coffee, done email reading, about to get back to inlining :)
08:48 brrt oh, yes, i'll gist it
08:51 brrt FROGGS: https://gist.github.com/bdw/e4ed70c4bd0de4f5d276
08:51 FROGGS thank you
08:51 brrt yes, i'm really happy to hear this
08:53 FROGGS very very nice
08:53 * moritz doens't understand much of that
08:54 brrt moritz: context is extending DynASM to use dynamic registers on x86_64 and ARM
08:54 brrt x86_64 being the main target, ARM the second
08:54 brrt they already work on x86, and I had assumed they worked everywhere
08:55 timotimo that sounds great!
08:55 moritz and we need dynamic registers, because otherwise we'd have to implement a register allocator in moarvm?
08:55 brrt no, just the other way arround :-)
08:56 brrt basically, if i want to compile: a = b + c, then thats a load b, load c, add b, c, store a, b , right?
08:57 brrt but, i need to know where a and b are loaded to emit the add instruction
08:57 moritz ah
08:57 brrt a 'real' compiler does this recursively
08:58 brrt or dynamic-programmingly, not important for this discusion :-)
08:58 brrt but that means you have to emit an instruction where you fill in the exact register later
08:58 brrt i.e. at runtime
08:59 brrt dynasm could do this but only for x86
08:59 moritz ok, now I understand
08:59 moritz thakns
08:59 brrt :-)
08:59 brrt for complete understanding, note that the alternative is to have the registers for the load's fixed (static allocation)
09:00 moritz I guess the alternative would be use a fixed set or registers, and push the old values on the stack, and restore them later
09:00 brrt exactly
09:00 moritz but we want to avoid that :-)
09:00 brrt more importantly - imho - if you do that, there is nothing intelligent you can do with regards to load / stores
09:01 brrt i.e. you can't say 'this value will be used 3 instructions later, and that will be the live value on the end of the basic block, so i can skip the store and emit it after the next instruction using it'
09:01 brrt that is not so important for now, as the first goal is to get jit compilation working at all
09:03 brrt (according to #luajit, this is all made significantly more complex by the fact that modern cpu's actually rename registes and apparantly can keep top stack values in registers, but we'll not worry about that soon)
09:10 timotimo yeah, in modern cpus, what your actual assembly instructions do and what the cpu does (and in what order) is ... different :)
09:16 nwc10 jnthn: the other 2 errors reported by valgrind in the paste remain, and are independent of the bug that you found and fixed
09:17 nwc10 and cause ASAN to be very unhappy and vomit ANSI codes.
09:17 jnthn Do you have the output against HEAD with latest line numbers?
09:17 nwc10 other 2 errors were introduced by ba6b4e37f8d99a9eaf3d20152052aa6e1024a153
09:18 nwc10 coming soon...
09:20 nwc10 jnthn: http://paste.scsys.co.uk/392732
09:21 nwc10 do you need longer stack backtraces?
09:22 jnthn No, I'll try and work from this; thanks.
09:23 jnthn 4 bytes before is significant, 'cus -1 gets used as a "no deopt entry here" sentinel value
09:23 jnthn *but* I'm very curious why that patch introduced it where it wasn't there before.
09:24 dalek MoarVM/inline: c00f594 | jnthn++ | src/spesh/inline.c:
09:24 dalek MoarVM/inline: Start detecting coderef/str/callsite refs to fix.
09:24 dalek MoarVM/inline:
09:24 dalek MoarVM/inline: They need fixing up in the case some some inter-compilation-unit
09:24 dalek MoarVM/inline: inlines. For now, just complains (so we know that's actually the
09:24 dalek MoarVM/inline: problem).
09:24 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/c00f59405a
09:24 dalek MoarVM/inline: 0cfd4af | jnthn++ | src/core/frame.c:
09:24 dalek MoarVM/inline: Ensure args always go in the right place.
09:24 dalek MoarVM/inline:
09:24 dalek MoarVM/inline: That is, we should always have | registers | args |. We got this wrong
09:24 dalek MoarVM/inline: in the inline case until now, overlaying the args buffer with some of
09:24 dalek MoarVM/inline: the inlinee's registers.
09:24 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/0cfd4aff4e
09:24 jnthn (no, those aren't about it)
09:25 nwc10 MOAR backtrace is a command line option, so easy to change: http://paste.scsys.co.uk/392735
09:29 nwc10 jnthn: even more current line numbers, after the previous 2
09:29 nwc10 http://paste.scsys.co.uk/392738
09:29 nwc10 AFK&
09:54 dalek MoarVM/moar-jit: 9848c72 | (Bart Wiegmans)++ | src/ (4 files):
09:54 dalek MoarVM/moar-jit: Indentation / whitespace fixes
09:54 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/9848c7285a
09:54 dalek MoarVM/moar-jit: a4fa5f9 | (Bart Wiegmans)++ | src/ (6 files):
09:54 dalek MoarVM/moar-jit: Rewritten JIT graph construction to do most of the work.
09:54 dalek MoarVM/moar-jit:
09:54 dalek MoarVM/moar-jit: This effectively moves most of the logic out of x86_64.dasc
09:54 dalek MoarVM/moar-jit: and into the jit.c file.
09:54 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/a4fa5f9aa0
09:54 * brrt &lunch
10:33 dalek MoarVM/inline: a0db232 | jnthn++ | src/ (4 files):
10:33 dalek MoarVM/inline: Prepare for comp units gaining extra constants.
10:33 dalek MoarVM/inline:
10:33 dalek MoarVM/inline: This is how we'll handle str/callsite/coderef constants when we inline
10:33 dalek MoarVM/inline: code from another compilation unit.
10:33 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/a0db232f11
10:33 dalek MoarVM/inline: ea9d487 | jnthn++ | src/ (3 files):
10:33 dalek MoarVM/inline: Handle cross-cu callsites in inline.
10:33 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/ea9d48724c
10:33 dalek MoarVM/inline: d0466b6 | jnthn++ | src/spesh/inline.c:
10:33 dalek MoarVM/inline: Fix cross-cu wvals in inline.
10:33 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/d0466b6bd3
10:36 brrt joined #moarvm
10:47 dalek MoarVM/inline: a1ad3b2 | jnthn++ | src/spesh/inline.c:
10:47 dalek MoarVM/inline: Fix a thinko.
10:47 dalek MoarVM/inline:
10:47 dalek MoarVM/inline: Just 'cus the code look like it'll do the right thing doesn't mean it
10:47 dalek MoarVM/inline: actually will...
10:47 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/a1ad3b2e85
10:47 dalek MoarVM/inline: c079349 | jnthn++ | src/spesh/graph.c:
10:47 dalek MoarVM/inline: Add missing sanity check in deopt rebuild.
10:47 dalek MoarVM/inline:
10:47 dalek MoarVM/inline: Hopefully resolves issue valgrind picked up reported by nwc10++.
10:47 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/c079349e35
10:49 nwc10 was actually ASAN. I just used valgrind to get the stack traces
10:52 jnthn ASAN++
10:54 woolfy1 left #moarvm
11:01 FROGGS from reading the commits it seems like inline is not trivial :o)
11:03 FROGGS ohh, and with Python a1ad3b2e85 would not be needed
11:11 dalek MoarVM/inline: bbcbdec | jnthn++ | src/ (3 files):
11:11 dalek MoarVM/inline: Fix up cross-CU string constant usages.
11:11 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/bbcbdecf03
11:11 dalek MoarVM/inline: 20cc072 | jnthn++ | src/spesh/inline.c:
11:11 dalek MoarVM/inline: Fix operand thinko in wval fixup.
11:11 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/20cc072451
11:12 nwc10 jnthn: our old friend t/spec/S17-lowlevel/lock.rakudo.moar still fails
11:12 nwc10 t/spec/S17-supply/batch.t failed during the test, but passed on a re-run
11:12 nwc10 otherwise, all happy
11:12 nwc10 so yes, you seem to have found and fixed the bug
11:14 jnthn :P
11:14 jnthn FROGGS: No, it's not trivial. Trickiest thing I've worked on for a while.
11:15 Util joined #moarvm
11:15 woolfy joined #moarvm
11:15 woolfy left #moarvm
11:23 jnthn nwc10: Nice :)
11:38 nwc10 jnthn: after your latest changes, all is fine apart from the perennial t/spec/S17-lowlevel/lock.rakudo.moar
11:43 nwc10 what's the overhead of making a call? Perl 5 has no resource allocation in the steady state, so is MoarVM similar?
11:44 jnthn "It depends"
11:44 jnthn But typically calls should hit the frame cache, which avoids allocating.
11:45 nwc10 that's good enough for my arm-wavy "steady state"
11:47 brrt jnthn, if i have a bytecode segment constructed in nqp, compiled with the MAST compiler, how do i invoke it?
11:47 FROGGS joined #moarvm
11:48 brrt or, what kind of object does the mast compiler return, anyway
11:49 brrt nm, i'll get there eventuall
11:49 brrt eventually :-)
11:55 jnthn A compilation unit
11:55 jnthn Try nqp::compunitmainline($the_thing)
11:55 jnthn Which should give you an invokable thingy.
11:55 jnthn If all else fails, just gist me what you have and I'll take a look :)
11:55 brrt ok, i'll try :-)
11:55 brrt where are the nqp:: ops defined, anyway
11:58 jnthn src/vm/moar/QAST/QASTOperationsMAST.nqp
12:00 brrt add_core_moarop_mapping
12:00 brrt is see
12:01 brrt *i
12:03 brrt it works, by the way
12:05 jnthn "it"? :)
12:05 moritz the JIT compiler? :-)
12:06 brrt no, not yet that, the compunitmainline thingy
12:06 brrt :-)
12:06 brrt i expect big firework crashes on the jit compilation
12:07 brrt is there a way to get something like 1..10 in nqp?
12:08 moritz I don't think so
12:08 brrt it doesn't matter
12:09 * brrt and his hll conveniences
12:13 lue joined #moarvm
12:14 jnthn joined #moarvm
12:21 brrt ugh nearly there...
12:38 brrt .... const_i64_16
12:38 brrt fun!
12:42 brrt yes, sigsegv!
12:42 colomon joined #moarvm
12:44 jnthn You and me both... :(
12:47 * timotimo has frozen joghurt instead of segv
12:48 _sri joined #moarvm
12:49 nwc10 jnthn: have you considered buiding your tree on your Linux VM and seeing what valgrind says about the SEGV?
12:50 jnthn nwc10: The debugger tells me that it's an object with a corrupt STable point
12:50 jnthn *pointer
12:50 nwc10 bother
12:50 timotimo did you know you can get a gdb backtrace from an asan error?
12:51 * nwc10 knows that, and sometimes can remember the thing to stick a breakpoint on
12:51 nwc10 but if it's a heap error, I prefer to get valgrind to do it
12:51 jnthn oh...I think I might now what it is
12:51 timotimo OK
12:51 nwc10 as valgrind will also give me uninitialised variable errors, which might be the real cause of the bug
12:51 timotimo jnthn: you might now?
12:51 jnthn yeah, fail.
12:51 jnthn *know
12:51 timotimo that sounds good :)
12:52 FROGGS joined #moarvm
12:52 jnthn yeah. darn.
12:52 jnthn ugh.
12:54 brrt is there a way to compile moar with debug symbols?
12:54 jnthn Just configure it with --debug
12:55 brrt thanks :-)
12:56 krunen joined #moarvm
12:58 _sri joined #moarvm
13:02 colomon joined #moarvm
13:03 * brrt clearly doesn't know all there is to now about dynasm labels
13:04 timotimo much now today
13:07 brrt hmm somehow i don't think that 8 is a proper value for a pointer-to-mvmthreadcontext
13:09 moritz small pointer values are moar human-friendly; they allow you to build a personal relationship with the pointer!
13:10 brrt moar is nothing if not human friendly
13:11 brrt why you no dwim
13:13 ashleydev joined #moarvm
13:13 brrt ahum.... case: break
13:14 brrt corrupt bytecode stream oh goodie
13:17 jnthn Maybe the return went to the wrong place?
13:19 dalek MoarVM/inline: 1779732 | jnthn++ | src/spesh/dump.c:
13:19 dalek MoarVM/inline: Teach the spesh dumper about sslot operands.
13:19 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/1779732597
13:19 dalek MoarVM/inline: 7e4b6b6 | jnthn++ | src/spesh/inline.c:
13:19 dalek MoarVM/inline: Correct re-writing of remote-cu wvals.
13:19 dalek MoarVM/inline:
13:19 dalek MoarVM/inline: We can't just do this as we go, otherwise we end up with the rewrites
13:19 dalek MoarVM/inline: of the spesh slots pointing to wrong things.
13:19 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/7e4b6b6e96
13:19 jnthn Yay, no SEGVs in make test of NQP now. Just a bunch of failures...
13:19 _sri joined #moarvm
13:20 jnthn Don't know how to deopt_all from inline yet
13:20 jnthn And that one is just an NYI :)
13:20 brrt looks like it (wrt return)
13:21 brrt although, that'd be weird
13:28 * jnthn makes a cup of tea before attacking deopt_all
13:28 jnthn The other bug I notice is something to do with lexicals...hmm.
13:29 dalek MoarVM/moar-jit: bde5170 | (Bart Wiegmans)++ | foo.nqp:
13:29 dalek MoarVM/moar-jit: Added a test for JIT compilation.
13:29 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/bde5170c4f
13:42 * brrt has a sneaking suspsicion something is going wrong in pointer-manipulating dasm
13:43 brrt on the other hand, evidence of that is not so good
13:45 _sri joined #moarvm
14:06 * brrt is off for a bit
14:06 brrt left #moarvm
14:09 dalek MoarVM/inline: 583c69e | jnthn++ | src/ (5 files):
14:09 dalek MoarVM/inline: Restore ->code_ref and ->outer in deopt frames.
14:09 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/583c69e202
14:09 dalek MoarVM/inline: f5a4b36 | jnthn++ | src/spesh/deopt.c:
14:09 dalek MoarVM/inline: deopt_all of frame with inlines: main body case.
14:09 dalek MoarVM/inline:
14:09 dalek MoarVM/inline: This makes deopt_all work when we encounter a frame with inlines to
14:09 dalek MoarVM/inline: deopt, but we're not currently in an inlined piece of code, so there
14:09 dalek MoarVM/inline: are no frames to re-create.
14:09 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/f5a4b3629b
14:10 timotimo there can't be much left now :)
14:19 FROGGS timotimo: I also look at the branch name first, and hope it already hit master :o)
14:21 jnthn 16 NQP tests still fail
14:21 jnthn Didn't even try an NQP build.
14:39 FROGGS rakudo build you mean?
14:40 jnthn No, NQP
14:41 FROGGS how do you... ahh!
14:41 FROGGS :o)
14:42 jnthn I just have one already built :)
14:42 nwc10 jnthn: current stuff is into a setting compilation
14:42 FROGGS yeah, I was thinking that one has to build nqp in order to test it... but that is soo old fashioned :o)
14:42 nwc10 going home, may not be able to tell you whether it passed spectest for a while
14:43 nwc10 OK, it's got past the Rakudo tests and is into spectest
14:43 * timotimo is off for a brrt
14:59 colomon joined #moarvm
15:31 dalek MoarVM/inline: c46aab5 | jnthn++ | src/spesh/deopt.c:
15:31 dalek MoarVM/inline: First crack at deopt_all uninlining.
15:31 dalek MoarVM/inline:
15:31 dalek MoarVM/inline: Seems to work - or at least, makes 4 more tests pass. One test that
15:31 dalek MoarVM/inline: failed on deopt_all not being implemented does still fail, but that
15:31 dalek MoarVM/inline: may be unrelated.
15:31 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/c46aab5b50
15:31 dalek MoarVM/inline: 3b65cd7 | jnthn++ | src/core/ (2 files):
15:31 dalek MoarVM/inline: Avoid looking at junk memory in arg context.
15:31 dalek MoarVM/inline:
15:31 dalek MoarVM/inline: A deopted frame doesn't have arg processing set up.
15:31 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/3b65cd7931
15:34 nwc10 jnthn: the usual, plus t/spec/S32-io/IO-Socket-Async.t failed, passes on a re-run
15:38 jnthn k
15:54 dalek MoarVM/moar-jit: ae6e4ed | (Bart Wiegmans)++ | src/ (6 files):
15:54 dalek MoarVM/moar-jit: Invoke a JIT function. Returning doesn't work yet.
15:54 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ae6e4edf42
15:57 dalek MoarVM/inline: 9baf6a6 | jnthn++ | src/spesh/codegen.c:
15:57 dalek MoarVM/inline: Sanity check to ensure inline offsets are written.
15:57 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/9baf6a64f9
15:57 dalek MoarVM/inline: e9c55d9 | jnthn++ | src/spesh/manipulate.c:
15:57 dalek MoarVM/inline: Move inline start annotations when deleting ins.
15:57 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/e9c55d906a
15:57 jnthn Turns out that last one accounted for all manner of bother.
15:57 jnthn Not sure I quite believe it, but I'm down to 1 failing NQP test now.
15:58 jnthn Spesh inline: unexpected num_pred
15:58 jnthn hmm
15:58 FROGGS O.o
15:58 jnthn That sounds like "the impossible happened"... :)
15:58 FROGGS jnthn++
16:08 dalek MoarVM/moar-jit: b7f0f73 | (Bart Wiegmans)++ | src/core/interp.c:
16:08 dalek MoarVM/moar-jit: Returning from JIT now works.
16:08 dalek MoarVM/moar-jit:
16:08 dalek MoarVM/moar-jit: It turns out that when you have to return from
16:08 dalek MoarVM/moar-jit: your frame, you really have to return from your
16:08 dalek MoarVM/moar-jit: frame, and not just forget it and hope for the
16:08 dalek MoarVM/moar-jit: best :-)
16:08 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/b7f0f732ce
16:11 jnthn Hmm, in the long run we'll want a variant of try return that is suitable for the JIT to caller. But yeah, that works for now :)
16:22 dalek MoarVM/inline: cf95c3e | jnthn++ | src/spesh/inline.c:
16:22 dalek MoarVM/inline: Liberalize pred tweaking during inline.
16:22 dalek MoarVM/inline:
16:22 dalek MoarVM/inline: We sometimes get a topology where the invoke is already the final
16:22 dalek MoarVM/inline: thing in a basic block, and other things jump to immediately after
16:22 dalek MoarVM/inline: it (mostly clearly happens with invoke_v). Cope with this scenario.
16:22 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/cf95c3eb8e
16:23 jnthn Well, that's NQP tests clean with inline enabled.
16:23 jnthn Amazignly, that's with GC updates not done.
16:24 jnthn Rakudo's build blows up at Grammar.nqp, which I'm hoping is thanks to that. Cool it gets through the steps up to that, mind...
16:26 jnthn OK, walk, dinner, GC updates to cope with frames carrying inlinings, then will see if I can get NQP building atop of moar with inlining.
17:06 FROGGS joined #moarvm
17:07 FROGGS brrt++ # b7f0f73 :o)
17:35 lizmat joined #moarvm
17:35 vendethiel joined #moarvm
17:38 nwc10 jnthn: nothing broken at cf95c3eb8ed0221
17:38 woolfy joined #moarvm
17:41 brrt joined #moarvm
17:43 woolfy joined #moarvm
17:53 lizmat joined #moarvm
18:00 woolfy joined #moarvm
18:15 nebuchadnezzar o/
18:15 FROGGS hi nebuchadnezzar
18:19 nebuchadnezzar is /usr/lib/MAST required in that place? couldn't it be installed under /usr/share/ since the .nqp files seems arch independent?
18:20 nebuchadnezzar it seems to be “planned” in FROGGS comment for NQP issue https://github.com/perl6/nqp/issues/154#issuecomment-33594960
18:22 FROGGS yes, but I had not enough time to do that actually :/
18:22 FROGGS .nqp files are source code files, like .pl
18:23 nebuchadnezzar I may do it as I need it to respect Debian policy ;-)
18:23 FROGGS that would be awesome :o)
18:24 nebuchadnezzar so I move it and modify nqp tools/build/Makefile-Moar.in to use the new path
18:25 nebuchadnezzar I wonder if nqp shouldn't use some pkg-config like stuffs to find where moar stuffs are
18:26 FROGGS that seems to be a good long time goal
18:28 nebuchadnezzar ok, will fill a request after diner ;-)
18:36 brrt joined #moarvm
18:43 brrt somethings odd with the return value
18:46 jnthn Try adding two even numbers, or two odd numbers? :P
18:47 brrt well, it increases with the run loop count
18:47 brrt so it seems somehow the jit frame is looking at the work registers of the parent frame
18:47 jnthn o.O
18:48 brrt yes
18:48 jnthn tssk, is github down...
18:49 dalek MoarVM/inline: 7d5d5d6 | jnthn++ | src/gc/roots.c:
18:49 dalek MoarVM/inline: Take into account inlining when GC marking frames.
18:49 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/7d5d5d69a2
18:49 jnthn ah, worked second attempt
18:49 jnthn Didn't try the NQP build yet, but the Rakudo one with inlining enabled now makes it to CORE.setting before exploding.
18:49 jnthn (And explodes 'cus a sanity check fails. So it knows its wrong.)
19:08 brrt hmm... it seems i have to propagate the MVMCompUnit through the spesh graph to get it to the jit compiler
19:08 brrt of
19:08 brrt or
19:08 brrt or not... hmm
19:09 jnthn Comp unit?
19:09 jnthn That's reachable through various means
19:09 jnthn including tc->cur_frame->static_info->body.cu or so
19:10 brrt that may be better
19:11 nwc10 jnthn: fine at 7d5d5d6
19:33 raiph joined #moarvm
19:33 masak nwc10: what is it you're testing, exactly?
19:41 jnthn masak: Making sure my inline branch - without the inlining enabled yet - doesn't bust the NQP/Rakudo build or introduced any errors asan can find.
19:42 masak ah.
19:42 masak nwc10++
19:43 masak jnthn: but you're building NQP/Rakudo with the inlining enabled, yes?
19:43 jnthn No, 'cus up until an hour or two ago it didn't even pass the NQP tests.
19:46 masak oh!
19:47 dalek MoarVM/inline: 71f3cde | jnthn++ | src/core/frame.c:
19:47 dalek MoarVM/inline: Fully NULL arg-related bits in deopt frames.
19:47 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/71f3cdeb23
19:47 dalek MoarVM/inline: 01efeea | jnthn++ | src/spesh/ (3 files):
19:47 dalek MoarVM/inline: Never delete inlined BBs.
19:47 dalek MoarVM/inline:
19:47 dalek MoarVM/inline: Technically, they may correctly become unreachable. For now, though,
19:47 dalek MoarVM/inline: we rely on the inline annotations not vanishing.
19:47 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/01efeea42c
19:47 dalek MoarVM/inline: 9fa0cf3 | jnthn++ | src/spesh/manipulate.c:
19:47 dalek MoarVM/inline: Make annotation movement a little more robust.
19:47 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/9fa0cf3393
19:49 jnthn With those it gets a good way into the setting of Rakudo
19:49 jnthn I'm currently trying an NQP build.
19:50 jnthn Much wow, it completed.
19:50 jnthn And the resulting NQP passes all the NQP tests.
19:51 nwc10 pinch yourself?
19:52 jnthn :P
19:52 jnthn Well, will still need to work out why the Rakudo setting build explodes.
19:53 jnthn Plus do an optimized build with spesh logging turned off to make sure it's actually faster... :)
19:54 jnthn oh, no explode this time
19:55 jnthn Error while compiling op p6decontrv: Spesh: failed to resolve extop in code-gen
19:55 jnthn ohhh
19:55 jnthn extops
19:55 jnthn hm.
20:02 dalek MoarVM/inline: d187eb9 | jnthn++ | src/spesh/inline.c:
20:02 dalek MoarVM/inline: For now, don't try to inline anything with extops.
20:02 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/d187eb93f5
20:02 * timotimo is getting excite
20:02 raiph d
20:03 [Coke] ment
20:05 jnthn Still a SEGV, sadly.
20:13 [Coke] exciteSEGV?
20:26 brrt back at segv :-)
20:29 bcode joined #moarvm
20:33 jnthn ah, phew, finally it segv'd under the debugger at a point that provided a godo clue.
20:33 jnthn *good
20:34 nwc10 jnthn: still good at d187eb93f5a381c67e9822837e2451db87ba3688
20:36 brrt ugh, callee save registers
20:39 dalek MoarVM/inline: 2a7aa82 | jnthn++ | src/spesh/inline.c:
20:39 dalek MoarVM/inline: Remember to initialize lexicals_start.
20:39 dalek MoarVM/inline:
20:39 dalek MoarVM/inline: Otherwise deopt will go copying all kinds.
20:39 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/2a7aa821da
20:39 masak joined #moarvm
20:39 sergot joined #moarvm
20:41 camelia joined #moarvm
20:49 jnthn Seems it survives CORE.setting now, including with an optimzied build
20:51 dalek MoarVM/moar-jit: 75a683a | (Bart Wiegmans)++ | / (6 files):
20:51 dalek MoarVM/moar-jit: Almost fixed returning a value.
20:51 dalek MoarVM/moar-jit:
20:51 dalek MoarVM/moar-jit: Bug is that whatever I do, the routine returns 81
20:51 dalek MoarVM/moar-jit: rather than 2 as I'd expect. It does somehow return
20:51 dalek MoarVM/moar-jit: the right value from the result register.
20:51 dalek MoarVM/moar-jit:
20:51 dalek MoarVM/moar-jit: Also added preliminary support for say() and const_s,
20:51 dalek MoarVM/moar-jit: but I need to figure out whether to load the pointer
20:51 dalek MoarVM/moar-jit: at runtime or at compile time, in which case I'll
20:51 dalek MoarVM/moar-jit: need to find the CompUnit then.
20:51 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/75a683a278
20:56 timotimo like teh sound of those :)
20:58 nebuchadnezzar \o/ beer powered
21:27 jnthn So, remaining task is to re-do the whole frame memory caching thing.
21:28 jnthn 'cus now any frame with something inlined in it just goes of to malloc, due to the variable sized thing.
21:28 jnthn Turns out that this is sufficiently inefficient it basically eats the benefits of inlining, or so it seems.
21:32 dalek MoarVM/inline: 76c98cc | jnthn++ | src/spesh/optimize.c:
21:32 dalek MoarVM/inline: Turn on inlining.
21:32 dalek MoarVM/inline:
21:32 dalek MoarVM/inline: Note that due to various restrictions, there are many things it will
21:32 dalek MoarVM/inline: not inline yet. Additionally, all spesh'd frames of non-standard size
21:32 dalek MoarVM/inline: fall back to malloc'ing the frames, which is enough of a pig to eat
21:32 dalek MoarVM/inline: many of the gains we get so far.
21:32 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/76c98ccf97
21:46 timotimo the pig eats all the grains?
21:47 jnthn Pretty much, though I knew this would need dealing with.
21:49 raiph Would redoing the frame mem stuff be an LHF for a decent C hacker?
21:55 raiph jnthn: I would be happy to post links to another of your awesome blog posts about progress, especially one that mentioned a couple LHFs with likely nice speedup payoffs. (Though, knowing you, by the time you read this you'll have not only worked out how best to redo it but done the coding too.)
21:57 jnthn Well, I'm on with the coding, but might leave it until tomorrow to finish it up :)
21:57 jnthn Granted the lock-free algo it wants is easy, but still...it's almost midnight :)
21:59 timotimo "malloc'ing the frames" means bypassing the frame cache?
22:00 jnthn timotimo: yeah
22:01 timotimo mhm, that does sound somewhat costly
22:02 timotimo will inlining be dumped in the regular spesh log?
22:03 japhb_ joined #moarvm
22:03 jnthn Well, you can see where it happened
22:04 jnthn Just search for Inline Start in the log
22:15 timotimo oke
22:16 jnthn Anyway, I think I probably hacked enough stuff up today :)
22:16 jnthn Got some fun (really) $dayjob thing to hack on tomorrow, but will work on the allocator thingy in the evening.
22:16 timotimo :)
22:30 lizmat joined #moarvm
22:30 woolfy joined #moarvm
22:40 jnthn 'night o/
22:40 lizmat gnight jnthn!
22:49 vendethiel joined #moarvm
23:12 woolfy left #moarvm
23:46 cognominal joined #moarvm

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