|
01:53
ilbot3 joined
|
|||
| Geth | MoarVM: MasterDuke17++ created pull request #656: == was a no-op, correct it to an = |
02:09 | |
| MoarVM: samcv++ created pull request #657: Rework MVMNFGSynthetic to not store base separately |
02:22 | ||
|
03:30
leedo joined
03:31
leedo joined
|
|||
| Geth | MoarVM: 62f66cbfd8 | (Samantha McVey)++ | src/strings/ops.c Ensure strings created with MVM_string_repeat are in NFG form Check that string a is stable under concatenation with itself before returning. If it isn't, then run it through re_nfg, similarly to what we do in MVM_string_concatenate. |
03:33 | |
|
03:40
leedo joined
05:02
Zoffix joined,
JimmyZ joined,
leedo_ joined
05:03
SmokeMachine joined
05:07
eater joined
05:37
brrt joined
|
|||
| Geth | MoarVM: c5b23f15f1 | MasterDuke17++ | src/spesh/optimize.c == was a no-op, correct it to an = |
05:41 | |
| MoarVM: 13bc298d66 | niner++ (committed using GitHub Web editor) | src/spesh/optimize.c Merge pull request #656 from MasterDuke17/fix_an_==_to_an_= == was a no-op, correct it to an = |
|||
|
06:15
lizmat_ joined
06:40
brrt joined
07:10
domidumont joined
07:14
domidumont joined
|
|||
| brrt | samcv: i'm still thinking you could initialize a grapheme iterator at the start of knuth_morris_parth | 07:14 | |
| also | |||
| *prath | |||
| and then, when the algorithm gives you a skip, you can just access that directly | 07:15 | ||
| and maybe, also do it only for very long Haystacks | |||
| (or measure it or something) | |||
|
07:23
domidumont joined
|
|||
| brrt | (graph.c is the refactor from hell :-() | 07:41 | |
| i broke something in inlines handling and i can't find what | 08:12 | ||
|
08:27
zakharyas joined
08:31
robertle joined
08:32
lizmat joined
08:51
SmokeMachine joined
08:53
lizmat_ joined
09:05
brrt joined
09:16
stmuk_ joined
09:56
Zoffix joined
|
|||
| brrt | hey jnthn | 10:47 | |
| it seems as spesh can drop or skip an inline | |||
| nine | Any pointers on how I get an entry label for a manually created JIT graph containing just a call of a C function? | ||
| brrt | if you've created the graph, you can make it compile with MVM_jit_compile_graph | 10:48 | |
| which will do all the necessary stuff | 10:49 | ||
| but | |||
| since we're allocating a new page and stuff, it is kind of heavyweight | |||
| nine | You mean the compile? That's done only once anyway | ||
| Right now my graph consists of a single MVM_JIT_NODE_CALL_C node. I strongly suspect, I need some kind of label node, too | 10:50 | ||
| Or whatever a label actually is | |||
| brrt | not really, no | ||
| well, actually | 10:51 | ||
| hmm | |||
| you should add a label (0) | 10:52 | ||
| and then, compile will dwim | |||
| nine | how do I do that? | ||
| brrt | you'd do something like... | 10:53 | |
| .tell jnthn i was kind of not expecting this; i'm mssing inline 0, and inlines not being….. initialized, i'm running into trouble | 10:54 | ||
| yoleaux | brrt: I'll pass your message to jnthn. | ||
| brrt | .tell jnthn: gist.github.com/bdw/815007b3e9adb5...27f8a8da62 | ||
| yoleaux | brrt: What kind of a name is "jnthn:"?! | ||
| brrt | .tell jnthn gist.github.com/bdw/815007b3e9adb5...27f8a8da62 | ||
| yoleaux | brrt: I'll pass your message to jnthn. | ||
| timotimo | brrt: the error happens inside spesh_codegen? | 11:00 | |
| brrt | nah, it's during JITting | ||
| the inlines array in more recent version of the vector library is zeroed | |||
| timotimo | the inline isn't put into the tree built by "children", but that's been that way ever since we inlined | ||
| brrt | but in this old version that i'm being rebased on master, it's not | 11:01 | |
| *that i'm rebasing | |||
| timotimo | vector library? | ||
| brrt | so that's my issue | ||
| dynamic array | |||
| src/core/vector.h in even-moar-jit | |||
| timotimo | ah | ||
| nine | Holy cow! It works! | 11:04 | |
| I just added a label node with label.name = 0 and the se segfault is gone :) | 11:05 | ||
| brrt | gist.github.com/bdw/b03c3de02750f9...it-graph-c | 11:06 | |
| cool! | 11:07 | ||
| yeah, the jit uses a dynamic label to restore after trampolining | |||
| and that has to be label[0] to be correctly initialize | |||
| d | |||
| although that code i just showed would never work | 11:08 | ||
| (and i think you're going to need labels_num to be set to a correct number as well?) | 11:09 | ||
| nine | nativecallinvoke will now use the JITed code for calling void foo(void) functions completely without dyncall | ||
| brrt | are you making a new frame for it? | 11:12 | |
| or will you just JIT it inline? | |||
| nine | Right now MVM_nativecall_build JITs and stores the code in a new field in the MVMNativeCallBody. MVM_nativecall_invoke takes it from there. But it currently has to cheat by temporarily overwriting cur_frame->jit_entry_label. | 11:14 | |
| Ideally I will be able to get rid of the nativecallinvoke op entirely and thus of the copying of arguments into an nqp::list | 11:15 | ||
| timotimo | oooooh | 11:16 | |
| nine | I already build the whole sub that contains the nativecallinvoke op at runtime. So I will probably find a way :) | 11:17 | |
| brrt | awesome | 11:23 | |
| good thing trains are slow | |||
| nine | Ok, hang in t/04-nativecall/20-concurrent.t is also fixed now | 11:28 | |
| Actually I may want to get into the avoiding nativecallinvoke business right away as handling of any arguments will be entirely different there | 11:32 | ||
|
11:36
domidumont joined
|
|||
| Geth | MoarVM/jit-legacy-cleanup: 06389bd07a | (Bart Wiegmans)++ | 3 files Introduce a small dynamic array library This generalizes a pattern of having growing collection in a malloc-backed array, and is heavily used in the expression JIT compiler. |
11:42 | |
| MoarVM/jit-legacy-cleanup: ddac5fdb84 | (Bart Wiegmans)++ | 3 files Use dynamic arrays for JIT building graph This effectively makes the JIT graph 'mutable', thereby removing much of the need for a specialized 'builder' object. As a result, I've changed the interface of the graph builder 'methods' to take a graph directly. |
|||
| MoarVM/jit_nativecall: 187ab6207e | (Stefan Seifert)++ | 4 files JIT native calling void func(void) functions. MVM_nativecall_build builds a JIT graph manually and compiles it. The result is attached to the MVMNativeCallBody. For now nativecallinvoke will enter that code using a hack to replace cur_frame->jit_entry_label. Ideally we will replace the whole frame containing the nativecallinvoke by the JITed code. |
11:48 | ||
| nine | I think I will add a new nativecallinvokejit op and have nativecallbuild return whether we JITed or not. Then I can tailor the native sub body. | 11:51 | |
|
11:52
cognominal joined
|
|||
| nine | Darn....as the train is so late anyway, they decided to have it just end in Innsbruck instead of going to Zurich | 11:53 | |
| Ok, different train now. Seat reservation was for nought. No idea how to go on past Zurich... | 12:10 | ||
|
12:12
SmokeMachine joined
12:20
lizmat joined
12:26
zakharyas joined
|
|||
| brrt | nine, fwiw, i think you can get away with stacka-allocating all of that | 12:52 | |
| because your leaking :-P | |||
| also, sucks to hear about the train | |||
| nine | Ah, that answers the question if I need any of this after the MVM_jit_compile_graph call :) Thanks! | 12:57 | |
|
13:03
lizmat joined
|
|||
| nine | "const_iX NYI" is a rather unexpected result of adding the nativecallinvokejit op | 13:09 | |
| Could also be the result of giving nativecallbuild a return value | 13:10 | ||
| brrt | that is unexpected, where does it die? | ||
| oh, that's probably because your offset in the bytecode stream is wrong | |||
| nine | Ah, yes, forgot to adjust the cur_op += | 13:11 | |
| All tests successful. That's rather scary :) | 13:12 | ||
|
13:29
domidumont joined
|
|||
| Geth | MoarVM/jit_nativecall: d8e7727a80 | (Stefan Seifert)++ | src/core/nativecall.c Fix create_caller_code leaking memory |
13:53 | |
| MoarVM/jit_nativecall: de3be33365 | (Stefan Seifert)++ | 8 files New nativecallinvokejit OP This OP just invokes the JITed code which will handle argument fetching on its own so we can avoid the overhead of copying arguments into an nqp::list. |
|||
| nine | Coming closer to Switzerland now so I will probably lose network at some point | 13:56 | |
| brrt | interestingly, we can't handle vargs at all | 13:57 | |
| jnthn waves from Lausanne | 14:55 | ||
| yoleaux | 04:52Z <MasterDuke> jnthn: in the atomicint example in the docs `my atomicint $total = 0; start { for ^20000 { $total?++ } } xx 4; say $total;`, shouldn't it be `await start`? with await i always get 80000 printed, without it's always some random number less than that | ||
| 10:03Z <Zoffix> jnthn: I added the missing `awaits` in atomic docs | |||
| 10:54Z <brrt> jnthn: i was kind of not expecting this; i'm mssing inline 0, and inlines not being….. initialized, i'm running into trouble | |||
| 10:54Z <brrt> jnthn: gist.github.com/bdw/815007b3e9adb5...27f8a8da62 | |||
| jnthn | .tell brrt inlines can become dead code; there's a table of which ones did | 14:56 | |
| yoleaux | jnthn: I'll pass your message to brrt. | ||
| Geth | MoarVM: pmurias++ created pull request #658: Avoid evaluating arguments to MVM_ASSERT_NOT_FROMSPACE |
15:32 | |
|
15:35
brrt joined
|
|||
| brrt | thanks jnthn, i figured the bug was in my own code :-) | 15:36 | |
| yoleaux | 14:56Z <jnthn> brrt: inlines can become dead code; there's a table of which ones did | ||
| brrt | rebasing is some scary stuff… | 16:01 | |
| Geth | MoarVM/jit-legacy-cleanup: 362ba7956b | (Bart Wiegmans)++ | 3 files Cleanup jit graph after use Since we now allocate the inlines, deopts etc. using malloc, we have to free them after we're done. |
16:04 | |
| MoarVM/jit-legacy-cleanup: fa7d818ca2 | (Bart Wiegmans)++ | 6 files Replace explicit JIT function return frame check This greatly simplifies the JIT compiler driver and jump-out logic. MVM_frame_try_return is now called within the JIT-compiled code. |
|||
|
16:19
geekosaur joined
|
|||
| Geth | MoarVM: Skarsnik++ created pull request #659: Add a source_address parameter to the connect instruction. |
16:27 | |
|
16:31
dogbert11 joined,
robertle joined
17:00
domidumont joined
|
|||
| samcv | good * everyone :) | 17:33 | |
| Zoffix | \0 | ||
| Geth | MoarVM: de7415bc65 | MasterDuke17++ | src/io/syncsocket.c Add error string to 'failed to resolve' exception |
17:55 | |
| MoarVM: 01a35b2790 | MasterDuke17++ | src/io/syncsocket.c Shorten text of 'failed to resolve' exception |
|||
| MoarVM: 78b3395534 | (Samantha McVey)++ (committed using GitHub Web editor) | src/io/syncsocket.c Merge pull request #652 from MasterDuke17/add_error_string_to_failed_to_resolve_exception Add error string to 'failed to resolve' exception |
|||
|
17:56
AlexDaniel joined
17:59
brrt joined
18:04
AlexDaniel joined
18:34
leont joined
20:36
geekosaur joined
21:27
lizmat joined
|
|||
| MasterDuke | param_op_i causes INTERPOLATE to bail. it looks like none of the param_* ops are jitted, is that because cur_op increases by a variable amount? | 21:31 | |
|
21:31
dalek joined
|
|||
| MasterDuke | oops, param_op_* ops | 21:32 | |
| timotimo: looks like you're around, have any idea about ^^^? | 21:38 | ||
| timotimo | param_* ops involve a function that returns a struct | 21:39 | |
| the exact way that happens isn't defined sanely in any ABI | |||
| so trying to naively jit it gets you crashes | 21:40 | ||
| MasterDuke | ah, nine's recentish commits | ||
| timotimo | yeah | ||
| time for some card games | 21:41 | ||
| MasterDuke | fun, what games? | ||
| Geth | MoarVM/master: 9 commits pushed by (Samantha McVey)++
|
21:55 | |
|
22:15
dogbert11 joined
|
|||
| timotimo | the "against humanity" card games | 23:06 | |
| MasterDuke | ah, played a couple times | 23:09 | |
| btw, any reason i couldn't do the same thing for param_op_i that nine did for param_rp_i? i.e., return the MVMArgInfo's .i64 instead of the MVMArgInfo itself? | 23:11 | ||
|
23:16
lizmat joined
|
|||