Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-06-10

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

All times shown according to UTC.

Time Nick Message
00:14 timotimo the word "macro" seems like a good fit here
02:03 jnap joined #moarvm
05:41 brrt joined #moarvm
05:41 brrt \o #moarvm
05:41 brrt http://www.freelists.org/post/luajit/runtime-variable-register-in-dynasm,5 may be of interest
05:42 brrt .tell jnthn that i can see how macro's would work, and that for x64 it would mean a matter of preprocessing
05:43 brrt also, i've tested it out, and for the first few registers - rax up to rsp - dynamic register access actually works, but it brings us right back into register starvation :-)
06:05 nwc10 jnthn: not broken.
06:38 brrt which would be enough to prove the point, though
06:38 brrt hmm
06:49 FROGGS joined #moarvm
07:08 zakharyas joined #moarvm
08:23 nebuchadnezzar nwc10: thanks, proposing patches was my first intention, I was confident that #moarvm will be happy with them ;-)
09:07 brrt joined #moarvm
09:13 jnthn urgh
09:13 * jnthn slept awfully...
09:23 brrt how come :-)
09:23 brrt morning, though
09:30 * brrt is wondering if it would be more difficult to write an x86-64 assembler or to patch up dynasm, but suspsects the former
09:31 nwc10 code is a liability
09:31 nwc10 if it's not a core differentiator, it's a liability, not an asset
09:32 nwc10 ie, if you can get patching back upstream, that's best
09:33 brrt i agree
09:41 jnthn brrt: How bad is the preprocessing route, and to what degree can it wait and we do the naive thing first?
09:42 brrt the preprocessing route is bad
09:42 * jnthn suspected so
09:43 brrt to give you an idea, there are 16 general-purpose 64-bit size registers, and 3 addressing mode of interest, so i can have the combination of 16x16 registers x 3 addressing modes, per opcode
09:43 brrt there are 8 or so floating point registers, and much the same story applies to them
09:44 jnthn On "will never lead to much better performance than what the interpreter can do" - it would still be quite a lot better due to (1) not needing to do any instruction decoding, (2) not needing to do the switch thing, (3) do way better on cache and branch prediction.
09:44 brrt that is fair
09:44 jnthn It depends on overhead.
09:44 jnthn For ops like set, add, etc. the decoding overhead dominates the operation cost.
09:45 brrt uhuh
09:45 jnthn And since spesh turns many attribute accesses into cheap pointer operations, those are dominated too
09:45 jnthn Same with sp_getarg_*
09:45 jnthn And arg_*
09:45 brrt well, for compiling instruction-per-instruction, i don't need a jit tree
09:46 brrt the naive route is admittedly tremendously simpler
09:47 brrt i.e. it /could/ be feasable to take interp.c, have gcc compile it to assembler, do some transformations to reduce the indirection caused by operand decoding, and stitch it together in a dasc file
09:48 jnthn Well, you don't *need* one, but (a) having one - even a basic one - will provide a way to move beyond that approach in the future, and (b) the "this ops is just this C function call" decision has to be made once and that knowledge can be re-used over different CPUs.
09:51 brrt hmm, yes, thats true
09:52 brrt in case it wasn't apparant, my idea in the jit tree was to take all indirections out into the open and use tree rewriting to write the code
09:52 brrt i can suppose it wasn't, it was an unclear post i think
09:54 jnthn Yeah, I can see that may be a step too far without the dynamic register stuff...
09:55 brrt to rephrase what i really meant, is: making indirections visible will help nothing in code generation if i can't select registers dynamicly
09:55 brrt that, yes
09:55 brrt :-)
09:56 brrt ultimately the optimum would be patching dynasm
09:57 brrt the 'near peak' is static register allocation and perhaps stuff like operation merging (peephole-style transformations)
09:57 brrt i ... think we all agree we should go for the near peak first
09:57 FROGGS Please send general questions to the LuaJIT mailing list. You can also send any questions you have directly to me:
09:57 FROGGS E-Mail: web-07@luajit.org
09:58 FROGGS brrt: I suppose a small chat with Michael Pall make sense here
09:58 jnthn brrt: Yes, I think so.
09:58 brrt i suppose so too FROGGS :-)
09:59 jnthn Well, yeah, his estimate on the amount of work needed to patch dynasm to support dynamic registers may be worth having
09:59 jnthn Like, is it an O(day), O(week), etc task.
09:59 brrt ok, i'll mail him for that :-)
10:04 jnthn But yeah, that aside, near peak working would still be a very meaningful improvement.
10:09 brrt sent, i'll see what i hear
10:09 * brrt &lunch
10:34 brrt joined #moarvm
10:41 brrt is having tea at 27 degrees c mad?
10:41 jnthn Yes. Tea should either be ice-tea and cold, or not ice tea and thus much hotter.
10:42 jnthn Oh wait, you didn't mean the temperature of the tea...
10:42 jnthn I'd say it's mad but I'm sipping coffee in similar temperatures here in Sweden :)
10:43 brrt :-) i've had coffee to, but i've run out of it
10:43 jnthn Which also seemed like a good idea at the time... :)
10:44 brrt why so hot? and to think i have to get out, too
10:47 jnthn It's even hot in Sweden, dammit.
10:47 jnthn Well, this bit of Sweden.
10:47 jnthn Clearly I need to find a further north place to move ot.
10:47 jnthn *to
10:52 nwc10 jnthn: you wouldn't like Vienna
10:53 jnthn nwc10: I used to live an hour away from there, and am well aware it can touch 35C or so in those parts in the summer.
10:54 nwc10 I suspect that the swimming is better here. Lots of bonus bits of Danube
10:54 jnthn True :)
10:59 jnthn My bit had the cheaper beer, though. :)
10:59 brrt wow, vienna is 33 degrees
10:59 jnthn Which is another cooling strategy :)
10:59 brrt (according to the google)
11:01 jnthn Prague, another city I sometimes feel a vague temptation to move to, is hitting 32 today also.
11:01 jnthn I guess if I want to do central Europe again I'll just have to learn to cope with heat. Or find a place with aircon :P
11:01 brrt or flee the summer
11:01 jnthn Or that, yes.
11:01 jnthn Summer home in Svalbard or something. :)
11:02 nwc10 if Scotland votes for independance, will it qualify for your grand tour of S?
11:02 brrt nice
11:02 jnthn .oO( Summer in a place you can bear )
11:02 jnthn nwc10: hah, I'd not thought of that. But yes. :P
11:03 * brrt wonders what is up with all those regions wanting to be states
11:06 moritz well, Scotland has a long and bloody history of that
11:06 moritz when you consider that, the proceedings are the most civilized of all the recent ones
11:12 brrt that is true
11:14 moritz also my impression of Scotland (from 2006/2007) was that they love to hate the English, but that they love other stuff even more, like the English health care system, the common currency, and similar stuff
11:18 FROGGS brrt: can you join #luajit please?
11:18 brrt yes, of course
11:18 * brrt wonders why he hadn't thought of that
12:12 brrt helpful discussion at #luajit indeed
12:12 brrt they suggest using llvm as a codegen
12:12 brrt not sure if that helps all that much
12:13 nwc10 it gets you a lot more platforms
12:13 brrt that is true
12:13 nwc10 it costs you, um, a need for C++
12:14 brrt among other things :-)
12:14 nwc10 and possibly more resources in other places
12:14 nwc10 and yes, I'm not sure
12:14 brrt people typically use a special thread just for llvm
12:14 nwc10 but all the cool kids are using llvm currently, so you get a lot of other people's work for free
12:15 brrt at the cost of magic
12:15 brrt (yes, my mood has a cynical turn today, i'm sorry, i'll be more optimistic some other day)
12:15 brrt (when it is cooler, probably)
12:15 nwc10 or when it's a public holiday again? :-)
12:16 brrt well, i don't really care for public holidays right now as i'm totally freeeeee :-)
12:16 brrt for the summer
12:18 brrt anyway, &appointment
12:21 brrt left #moarvm
12:23 jnap joined #moarvm
12:39 lizmat .oO( totally freeee  != free from appointments )
12:39 jnthn .oO( or writing a JIT compiler :P )
12:40 jnthn I really don't think dragging in llvm is the way to go. Heck, it's huge... And I really don't want to have to deal with C++.
12:42 jnthn I'm not quite sure why "build the best imaginable JIT" is becoming a goal. We don't have one *at all* yet. Dealing with all the places in the VM that aren't JIT-ready is going to be tough enough.
12:42 jnthn Getting deopt+JIT figure out for a simple one will be hard enough too.
12:43 jnthn And code-gen is just one small part of the overall performance story.
12:43 jnthn More of the kinds of things spesh does, plus inlining, OSR, and escape analysis are also huge factors.
12:46 jnthn What most VMs call their JIT is actually what we're calling spesh+JIT, which obscures things a bit. Eliminating the interpreter overhead *in combination* with the other things spesh does/will do (noting many of the transforms it does are turning costly operations into cheap ones that suffer interp overhead more) will help a good bit already.
12:57 nwc10 jnthn: meaning that LLVM is the wrong choice in the near term, because there's a lot more win to be had from a KISS approach to the actual codegen part, because that's not actually where the hard stuff is?
12:57 nwc10 and maybe the wrong choice for the foreseeable future, not just the near term
13:08 jnthn nwc10: Well, I'm a lot more confident we'll get something viable and helpful (as in, actually lets people run Perl 6 programs faster than they can today) with such an approach to the code-gen itself, yes.
13:09 jnthn nwc10: For the longer term: harder to say. But I don't think we can work out the right longer-term options without doing the simple things first.
13:11 nwc10 that was what I'd sort of figured, but didn't say explicitly
13:12 jnthn Code-gen can be a big and complex area, but trying to do that in a highly clever way *and* having to tackle all the integration points between code-gen and the rest of the VM feels like a lot to bite off in a summer.
13:12 nwc10 that figuring out how to use llvm well needs the experience of starting with something simpler.
13:12 jnthn (As in, more than I think is reasonably possible.)
13:13 jnthn And I'm quite sure our downstream users would much prefer a sufficiently complete and useful JIT today that gives a 2x-3x improvement by eliminating interpreter overhead, than the a half-complete but will-be-super-awesome-someday JIT.
13:15 jnthn The additional factors will come from other opts, like inlining, and escape analysis, and more specialization, which turn costly operations into cheap ones.
13:16 jnthn (like, turning "invoke this method, creating it a callframe" into "goto" 'cus we've now gone and inlined that method)
13:16 donaldh joined #moarvm
13:17 donaldh left #moarvm
13:39 ggoebel111116 joined #moarvm
13:55 ggoebel111116 joined #moarvm
14:56 brrt joined #moarvm
14:56 brrt lizmat: doctors appointments trump everything, i'm afraid :-)
15:06 brrt jnthn, what happens if i use the mvm jit graph construction to do the following: linearize the bytecode stream, assign labels, convert some ops into c calls
15:07 brrt anyway, i have a more important issue to solve first
15:08 brrt 'where to insert the jit code and have it called'
15:09 brrt and fwiw, i agree on llvm being far too big
15:12 jnthn brrt: (jit graph) that sounds fairly sane as a starting point. Can desugar some ops a bit, I'd guess.
15:13 jnthn brrt: On "where to put it to have it called" - yes, that's interesting indeed. I wrote up a gist on some ideas on that a while back :)
15:14 brrt if you have it, i'd like to read it
15:14 jnthn Oh noes, you losted it :P
15:14 * jnthn goes to find it
15:15 jnthn https://gist.github.com/jnthn/c1b88756121f0525ff28
15:16 brrt the secret jit op, that solution, i recall
15:16 jnthn yeah
15:16 jnthn And hang the generated code off MVMSpeshCandidate
15:18 brrt not on the frame?
15:19 jnthn Oh, two levels hee
15:19 jnthn *here
15:19 jnthn Well, actually
15:19 jnthn Yeah, off the candidate would do
15:19 jnthn Why? Because cur_frame->spesh_cand->jitted will doit
15:22 brrt :-) ok
15:22 brrt so a whole frame has to be compiled right?
15:22 brrt i think you need a whole frame to form a graph
15:24 jnthn Yes
15:24 jnthn 1 spesh graph = 1 frame
15:24 jnthn Well, apart from I'm busy ruining that in a branch called inline
15:24 jnthn But even so, the difference doesn't matter to you even then - except deopt. :)
15:24 brrt after inline, it will reform to a single frame, so i don't care
15:24 brrt oh that is true
15:25 jnthn Well, in deopt we call back into the interpreter
15:25 jnthn Oh, I worked out how you can do it really easily :)
15:25 jnthn You'll just call into the deopt code path and explicitly pass it the deopt-point index and then fall out of the JITted code back into the interpreter, and deopt will ahve stuck it in the right place. :)
15:26 jnthn And the deopt point index hangs off a spesh annotation.
15:26 jnthn So it's readily available.
15:26 brrt i think things are starting to come together
15:27 brrt because i've also figured out pretty much how to emit a 'call-to-interpreter-and-return-here' scheme
15:27 brrt basically, emit a c call to MVM_frame_invoke() or something like that
15:28 brrt that sets up the interpreter
15:28 brrt also emit a label
15:28 brrt return the reference to that label
15:28 brrt and on the next entry, pass the same label again
15:28 brrt we might not return it but rather store it in a frame variable / work register
15:29 brrt that might even be better
15:29 jnthn Yeah, that sounds along the right lines.
15:29 jnthn I think that what we actually want is a MVM_frame_invoke_from_jit()
15:30 brrt thats quite alright to me to
15:30 brrt that is indeed probably better
15:30 jnthn Where if you're calling to another thing that happens to be JITTed, it returns you an address of the JITted code to jump to
15:30 brrt because you can have that function receive the label
15:30 jnthn And if it returns NULL you know you have to fall back to the interpreter.
15:30 jnthn It *does* mean you'll be essentially doing a tail call
15:31 jnthn Return needs the same thing, fwiw. Apart from in the return to JITted code from JITted code case it's just jumping to the label, like you said.
15:31 jnthn And if it returns NULL then again, you know to fall back into the interpreter.
15:31 brrt uhuh
15:32 jnthn Which leaves the forth quadrant - interpreted code returning to JITted code - which just gets pointed to some (maybe different) enter JIT op.
15:32 brrt yes
15:32 brrt we might need to add a flag to the frame, to tell the interpreter that it is running jitted code
15:33 jnthn We might, though we can also infer it from f->spesh_cand->jitcode not being NULL, maybe, and then just hide it behind a function.
15:34 brrt that works, too
15:35 brrt ok, i'm going to write some stuff down now
15:35 * brrt feels like this is the most productive discussion he has had all day
15:44 jnthn :)
15:44 jnthn Aye, well, it seems things are less blocked now :)
15:59 brrt yes, that is how it feels to me too
15:59 brrt some branches of the tree of possibilities have been culled
16:10 dalek MoarVM/moar-jit: 9aefa41 | (Bart Wiegmans)++ | src/ (5 files):
16:10 dalek MoarVM/moar-jit: Used macros and type maps to clean up jit codegen.
16:10 dalek MoarVM/moar-jit:
16:10 dalek MoarVM/moar-jit: Minor change, but I've also moved MVMJitCode to types.h
16:10 dalek MoarVM/moar-jit: so that MVMSpeshCandidate can now refer to it (doesn't yet).
16:10 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/9aefa41922
16:15 FROGGS joined #moarvm
16:36 jnap joined #moarvm
16:38 jnap1 joined #moarvm
16:55 vendethiel joined #moarvm
17:15 dalek MoarVM/inline: e738af3 | jnthn++ | src/spesh/deopt.c:
17:15 dalek MoarVM/inline: Implement multi-frame uninlining.
17:15 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/e738af328f
17:16 dalek MoarVM/inline: 478b111 | jnthn++ | src/spesh/deopt.c:
17:16 dalek MoarVM/inline: Tweak deopt debugging help.
17:16 dalek MoarVM/inline:
17:16 dalek MoarVM/inline: Could do something more formal that this, like write to the spesh log,
17:16 dalek MoarVM/inline: or start keeping a deopt log.
17:16 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/478b111056
17:16 brrt joined #moarvm
17:18 brrt left #moarvm
17:32 jnthn With that, first 2 NQP tests are passing again :)
17:44 jnthn Seems the next issue is missing spesh slot values..hm.
17:46 nwc10 jnthn: just to check - is your fridge big enough for all the beer you deserve after you get this working?
17:47 TimToady fortunately, deserved beer can be lazily evaluated much of the time
17:54 jnthn :)
17:55 jnthn Well, the fridge is big enough to hold the http://www.ratebeer.com/beer/great-divide-espresso-oak-aged-yeti-imperial-stout/85174/ that should be a sufficient reward. :)
18:06 nwc10 jnthn: origin/inline && master && nom not broken.
18:13 jnthn Darn, when I fix the speshslot bug the first 2 NQP tests hang. wat.
18:17 jnthn BB 6:
18:17 jnthn Instructions:
18:17 jnthn ...blah...
18:17 jnthn goto BB(6)
18:17 jnthn ...that may explain it. wtf :)
18:20 jnthn Well, dinner first, but it's a case where we inlined 3 things, but one of those things already had something inlined into it.
18:21 FROGGS ewww
18:22 jnthn Well, it's an *awesome* thing to be doing. I just checked into it.
18:22 jnthn Will debug why it's going wrong after food, but just to share what it's trying to do here, this is append:
18:22 jnthn method append(MAST::InstructionList $other) {
18:22 jnthn push_ilist(@!instructions, $other);
18:23 jnthn $!result_reg := $other.result_reg;
18:23 jnthn $!result_kind := $other.result_kind;
18:23 jnthn }
18:23 jnthn It figures it can inline all of result_reg, result_kind, and push_ilist
18:23 jnthn The latter two are trivial 'cus they just read attributes
18:23 jnthn push_ilist is as follows:
18:23 jnthn sub push_ilist(@dest, $src) is export { nqp::splice(@dest, $src.instructions, +@dest, 0);
18:23 jnthn }
18:23 jnthn Which is tiny, so again it makes sense to inline. But notice it calls .instructions - another cheap accessor.
18:24 FROGGS nice
18:24 jnthn And earlioer in the log we find:
18:24 jnthn Can inline instructions (cuid_31_1402147152.67041) into push_ilist (cuid_57_1402147152.67041)
18:25 jnthn So basically it flattens away 4 call frame creations once it's doing it right. Which is very cool.
18:25 jnthn Now I just need to wrok out why the push_ilist nested inline comes out looking utterly broken.
18:25 jnthn But I'm hungry. So, after noms :)
18:26 FROGGS nom well :o)
18:37 nwc10 jnthn: nice.
20:06 jnthn [Annotation: INS Deopt All (idx 1 -> pc 52)]
20:06 jnthn goto BB(3)
20:06 jnthn [Annotation: INS Deopt One (idx 0 -> pc 52)]
20:06 jnthn sp_guardconc r2(2), <nyi(lit)>
20:06 jnthn Successors: 2
20:06 jnthn oh dear. :)
20:07 FROGGS <nyi(lit)>?
20:07 jnthn no
20:07 jnthn That the goto has something after it
20:07 jnthn Oh, hmm...but that maybe isn't actually it.
20:07 jnthn oh, yeah, it's wrong.
20:08 jnthn Not sure if it's *the* issue, but it's pretty clear the goto should end the basic block :)
20:11 woolfy1 joined #moarvm
20:13 lue joined #moarvm
20:29 oetiker joined #moarvm
20:33 nwc10 joined #moarvm
20:33 xiaomiao joined #moarvm
20:33 cxreg joined #moarvm
20:33 ashleydev joined #moarvm
20:37 dalek MoarVM/moar-jit: be6071c | (Bart Wiegmans)++ | src/ (4 files):
20:37 dalek MoarVM/moar-jit: Try JIT compilation in candidate specialization.
20:37 dalek MoarVM/moar-jit:
20:37 dalek MoarVM/moar-jit: This adds a JITCode field to MVMSpeshCandidate, and if
20:37 dalek MoarVM/moar-jit: applicable compiles the jit graph. The jitcode_size field
20:37 dalek MoarVM/moar-jit: is for when we want to remove the code.
20:37 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/be6071c05d
20:58 lizmat_ joined #moarvm
21:00 woolfy joined #moarvm
21:03 dalek MoarVM/inline: ba6b4e3 | jnthn++ | src/spesh/ (2 files):
21:03 dalek MoarVM/inline: Don't put sp_log/guard in same BB as its invoke.
21:03 dalek MoarVM/inline:
21:03 dalek MoarVM/inline: This means that the inovke would fail to be the last thing in the BB,
21:03 dalek MoarVM/inline: but worse meant that we'd end up not checking the return guard when
21:03 dalek MoarVM/inline: doing an inline.
21:03 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/ba6b4e37f8
21:03 dalek MoarVM/inline: 3472f4d | jnthn++ | src/spesh/graph.c:
21:03 dalek MoarVM/inline: Make sure spesh slots are conveyed from inlinee.
21:03 brrt joined #moarvm
21:03 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/3472f4d550
21:03 jnthn Sadly, doesn't fix the issue, but would run into it soon enough anyway, so still worth fixing.
21:04 brrt what is 'the issue' here? :-)
21:06 donaldh joined #moarvm
21:07 jnthn brrt: There's some case where we inline a thing that also carried inlines
21:08 jnthn brrt: And end up messing up the graph.
21:08 brrt oh, hasty
21:08 brrt nasty
21:09 brrt if you have brainspace left, i've been meaning to ask
21:10 brrt where do we enter the jit code?
21:10 brrt (i know i asked this before)
21:10 brrt wait
21:11 brrt nm... i didn't ask it again, it just seems that way
21:11 brrt :-)
21:12 jnthn Well, in the end by exeuting a magical op like
21:13 jnthn MVM_OP_jit_enter:
21:13 jnthn tc->cur_frame->spesh_cand->jitcode(tc, tc->cur_frame);
21:13 jnthn goto NEXT;
21:13 jnthn And invoke just points the interp there instead of at the specialized bytecode.
21:14 brrt yes, and i just recalled how that should work :-) so that is why it was a dumb question
21:14 jnthn :)
21:14 jnthn I was thinking...I thought we did that ;)
21:14 brrt actually, the 'invoke points the interp there' was the part that was missing from my thought process
21:14 jnthn ah
21:14 brrt so thanks for filling that up :-)
21:14 jnthn See MVM_frame_invoke
21:15 brrt possibly i could create a static bytecode segment that simply runs MVM_OP_jit_invoke
21:15 jnthn Yeah, that'd do it
21:16 jnthn When you add jit_invoke in oplist, make sure to mark it .s
21:16 jnthn And put it at the end of the file
21:16 jnthn That way it can't appear in normal code
21:16 jnthn (.s means "spesh op")
21:17 jnthn (and after editing oplist, perl6 tools/update_ops.p6)
21:17 * brrt thinks we should add that to the makefile
21:17 jnthn I didn't because I never know quite which perl6 I'm gonna need to run it with.
21:18 brrt fair enough :-)
21:18 jnthn I've had situations where my install/bin/moar was busted enough I had to use perl6-p instead :)
21:18 jnthn (yes, I normally use bleeding-edge Moar to re-generate the Moar ops stuff :P)
21:18 brrt and why not? dogfood is nutricious
21:19 jnthn and tasty...wait... :P
21:20 brrt :-)
21:20 * jnthn goes for a stroll before it gets completely dark
21:21 timotimo it's already completely dark here :|
21:21 jnthn maybe I'll magically realize what's bust during it :)
21:21 timotimo that would be nice :)
21:21 * brrt wishes a good stroll
21:22 brrt (ugh, i should teach emacs not to use tabs in whitespace)
21:29 lizmat yes, please, no TABs  :-)
21:29 timotimo put it on my tab
21:39 woolfy1 joined #moarvm
21:39 * brrt will have to check out the many cases of tabs emacs has inserted by now
21:46 dalek MoarVM/moar-jit: e46bde6 | (Bart Wiegmans)++ | / (10 files):
21:46 dalek MoarVM/moar-jit: Add magic bytecode to invoke the JIT compiled function.
21:46 dalek MoarVM/moar-jit:
21:46 dalek MoarVM/moar-jit: During specialization, if we can compile the jit graph into
21:46 dalek MoarVM/moar-jit: a function, we now insert special a special opecode that will
21:46 dalek MoarVM/moar-jit: actually invoke that function.
21:46 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e46bde6b60
21:46 brrt that's it for today
21:46 * brrt off
21:47 brrt left #moarvm
21:56 * jnthn back
22:00 jnthn I'm guessing it could be dead instruction cleanup gone wild...
22:07 jnthn oh...the sucessors aren't updated correctly.
22:18 lizmat joined #moarvm
22:19 lizmat Mouq: hmmm... "use" is compile time: does it make sense to assume a directory will appear out of thin air during runtime?
22:19 lizmat and if so, wouldn't that be a serious potential security hole
22:20 jnthn lizmat: mischan?
22:21 lizmat mischan ?
22:22 lizmat oops, yes
22:31 timotimo jnthn: does that indirectly cause the goto to have code after it still?
22:35 jnthn timotimo: Already fixed that kind of bug earlier :)
22:43 timotimo ah ok
22:43 timotimo ah, i see that now
22:45 timotimo the jit stuff can now call into a "jit compiled function", but no compilation is done so far, right?
22:48 * jnthn didn't read the patches yet..
22:52 jnthn Ah...seems the reason it was still busted after I fixed the succ/pred setting was that there was a leftover hack...
22:56 jnthn yup.
23:01 dalek MoarVM/inline: 40042be | jnthn++ | src/spesh/inline.c:
23:01 dalek MoarVM/inline: Properly fix up BB succ/pred.
23:01 dalek MoarVM/inline:
23:01 dalek MoarVM/inline: Also remove a hack that kept things falsely alive before.
23:01 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/40042bedc1
23:08 jnthn Some more NQP tests passing again now.
23:09 jnthn Still a good bunch of failures to deal with.
23:28 jnthn Time for some rest...'night
23:29 timotimo gnite jnthn :)

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