|
01:20
FROGGS_ joined
05:02
bcode joined
06:05
bcode joined
06:59
zakharyas joined
07:00
FROGGS_ joined
|
|||
| nwc10 | jnthn: debug build completes, some spectests fail with SEGVs. Running one of them under valgrind, it passed, but valgrind complained about stuff. Didn't investigate that further, because... | 07:04 | |
| ASAN vomits ANSI color codes. Running the same thing with valgrind to get nicer stacktraces finds two problems: paste.scsys.co.uk/393371 | |||
|
07:05
dalek joined
|
|||
| nwc10 | first is because last_res_type is not initialised in uninline() | 07:05 | |
| second is because inlinee->deopt_addrs == inliner->deopt_addrs and the realloc code in merge_graph() doesn't consider that as a possibility | 07:06 | ||
| I don't know exactly what the right fix in either case is | |||
| in particular, whether the bug is in the realloc code, or that situation should never happen, so the bug is elsewhere | |||
| I aplogise for distracting you from your fun day at work work. | 07:07 | ||
|
07:11
synopsebot joined
|
|||
| FROGGS_ | morning | 07:13 | |
| dalek | arVM/moar-jit: e815b77 | (Bart Wiegmans)++ | src/jit/ (3 files): Fix jumping to exit. Apparantly, the addition code is broken because dynasm computes the wrong register offset, and nothing I do changes that. |
07:24 | |
|
07:36
brrt joined
07:56
odc joined
|
|||
| brrt is out of ideas wrt to the jit compiler bugs | 07:58 | ||
| .... or perhaps not totally out of ideas | |||
| basically, it looks as if there are off-by-one's introduced into the dynasm code at sompe laces | 07:59 | ||
| some places | |||
| and... i don't exactly know why | |||
| jnthn | Can you recreate the issue in an isolated example, free of the MoarVM bits? | 08:04 | |
| nwc10 | brrt: also, your branch as checked appears to be unbuildable elsewhere | ||
| I'm guessing there's at least one object file missing, and a link line to the dynasm library | 08:05 | ||
| brrt | i can't, thats the thing | ||
| nwc10 - i know its an issue i can fix :-) | 08:06 | ||
| oh, you don't need to link to dynasm, thats the beauty | 08:08 | ||
| its all self-contained in a header file | 08:09 | ||
| i'll fix the 'build without jit' case first | |||
| nwc10 | brrt: OK. Could you fix it - right now your branch is less useful than it could be, beacuse it's unbuildable. | ||
| dalek | arVM/inline: aa30bf3 | jnthn++ | src/spesh/deopt.c: Fix copy-pasto. Found by ASAN, reported by nwc10++. |
08:16 | |
| nwc10 | jnthn: technically *that* one was found by valgrind :-) | 08:17 | |
| as a side effect of trying to find the other one | 08:18 | ||
| moritz | "Found by @awesome-tools.pick(), reported by nwc10++" | ||
| nwc10 | it's possible to run everything with valgrind, but it's way slower | 08:19 | |
| and as I found out, you can DOS a machine that way | |||
| in future, ulimit | |||
| RAM, om nom nom nom nom (etc) | |||
| FROGGS | I didn't even know that DOS was that memory hungry :o) | 08:20 | |
| I've got disk images of 6.22 here if somebody needs it... *cough* *warez* *cough* | 08:21 | ||
|
08:22
lizmat joined
|
|||
| jnthn | nwc10: I think the other one - will check into it later - could be to do with trying to inline a recursive call, something it's still on my todo list to prevent it trying todo. | 08:22 | |
| nwc10: I'm not actually sure how it could happen anyway... | 08:23 | ||
| nwc10 | no, me neither, but the assert() catches it | ||
| jnthn | nwc10: But it'd explain the same pointers. | ||
| FROGGS | m: say ?NQPMu | ||
| camelia | rakudo-moar 60aaed: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/FRKGfZlD8Sā¤Undeclared name:⤠NQPMu used at line 1ā¤ā¤Ā» | ||
|
08:26
woolfy joined
|
|||
| dalek | arVM/moar-jit: 521b686 | (Bart Wiegmans)++ | src/jit/ (5 files): Fix jitless build stub |
08:30 | |
| brrt | nb, this is the build you'll get if you either a): lack lua (and lua bitop) or b): do not pass --enable-jit | 08:33 | |
| so by default, everyone :-) | |||
| i should look at that again | |||
| jnthn | brrt: Is that, you can pass --enable-jit without having Lua and it will work out, 'cus we check in the output of dynasm? | 08:34 | |
| brrt | you ought to be able to, but no | ||
| dumb check i left in | |||
| basically, preprocessing is a makefile rule | 08:35 | ||
| i should either just 'let it crash' if you are editing the dasc file without having lua | |||
| or check it at build-time | 08:37 | ||
| dalek | arVM/moar-jit: b8f9f55 | (Bart Wiegmans)++ | Configure.pl: Remove configure-time check for lua. Just let it crash if you modify dasc without having lua installed. |
08:41 | |
| brrt | your make installation will Do The Right Thing | ||
| hmm | 08:43 | ||
| or not | |||
| depends on whether make will see the .c file as up-to-date | |||
| xiaomiao | btw - annoying little buglet: bugs.gentoo.org/show_bug.cgi?id=510706 | 08:51 | |
| at some part of the build process the local absolute path is stapled in, but that ends up being very wrong | 08:52 | ||
|
09:16
zakharyas joined
|
|||
| dalek | arVM/moar-jit: ff8f477 | (Bart Wiegmans)++ | / (2 files): Warn rather than crash on preprocessor failure. Detect likely failure of the DynASM preprocessor during configuration and emit a warning line into the Makefile rather than a command that would crash. |
09:21 | |
| brrt | jnthn: this allows you to build with --enable-jit while not having lua installed | 09:22 | |
| at worst it will warn | |||
| nwc10++ for pointing me to it :-) | 09:40 | ||
|
10:13
woolfy left
10:20
woolfy joined,
woolfy left
11:40
brrt joined
12:28
jnap joined
12:35
FROGGS joined
|
|||
| brrt | much frustration | 12:51 | |
| y u no work | 12:52 | ||
| FROGGS | brrt: can I test your branch? | 12:53 | |
| brrt | sure | ||
| ehm, instructions are really simple | 12:54 | ||
| FROGGS | so I should build it with --enable-jit I guess | ||
| brrt | git checkout moar-jit; perl Configure.pl --enable-jit $options; make; make install; ./foo.nqp | ||
| :-) | |||
| ./foo.nqp makes known-compilable frame | |||
| if everything went 'well', it should work (i.e.) not crash but after 14 iterations you should see that the return value is no longer 4 | 12:55 | ||
| and you should stop seeing the 'oh hai' fragment as i haven't decided on string lookup just yet | 12:56 | ||
| fwiw, unless strings like that are known to move i /think/ we should look 'm up at compile time | |||
| jnthn | If the pointer is to something in gen2, you can always just put the literal pointer right into the machine code. | ||
| brrt | but that depends on gc details | ||
| ok, how do i figure that out? :-) | 12:57 | ||
| jnthn | If it's not made it to gen2 yet, it can still move | ||
| Encapsulate it, but you just check the collectable flags | |||
| There's am MVM_blah_i_forgot_GEN2 or so | |||
| See near top of 6model.h | |||
| nwc10 | which doesn't nest. | ||
| jnthn | What doesn't nest? | 12:58 | |
| nwc10 | turn on "direct to gen 2" | 13:00 | |
| call something | |||
| turn on "direct to gen 2" | |||
| turn off "direct to gen 2" | |||
| return | |||
| turn off "direct to gen 2" | |||
| jnthn | No | 13:02 | |
| We're talking about checking if a given collectable is already in gen2 | |||
| Not forcing allocation there. | |||
| nwc10 | ah OK, sorry for being a PEBKAC | ||
| jnthn | Granted that mechanism doesn't nest, though, which could be considered fragile | 13:03 | |
| Even more fragile is that it doesn't have a clue about exceptions, mind... | |||
| nwc10 | IIRC there's already one code path which nests (well doesn't) | ||
| and oh gosh, exceptions | |||
| yes, this is where Perl 5 ends up with a private little stack of things to undo | |||
| FROGGS | ./foo.nqp | 13:07 | |
| Unhandled exception: Bytecode stream version too high | |||
| /o\ | |||
| brrt | oh, i see | 13:13 | |
| you'll need to recompile nqp then :-) | |||
| (yes, that *****. it won't be necessary once i've merged with master) | |||
| jnthn | .oO( sucks isn't swearing... ) |
13:15 | |
| brrt | well.... i try to keep it family-friendly here :-) | 13:17 | |
| FROGGS | okay, will recompile nqp, hold on | 13:20 | |
| brrt holding on | 13:22 | ||
| FROGGS | Return value: 4 | ||
| Loop nr: 14 | |||
| Return value: 279172874291 | |||
| \o/ | |||
| brrt | yes | ||
| you can disassemble the output using objdump | |||
| (if everything went well, you should have a file 'jitcode.bin' | 13:23 | ||
| hangon, i'll give you the exact line | |||
| objdump -D -b binary -m i386:x86-64 -M intel jitcode.bin | |||
| aliased to disasm :-) in my file | |||
| .bashrc file | 13:24 | ||
| FROGGS | brrt: I've got something for ya: gist.github.com/FROGGS/8b90c0d93baccfee3acc | ||
| jnthn | FROGGS++ Valgrind++ | 13:25 | |
| brrt | oh..... that is such awesome | ||
| you are so many heroes right now | 13:26 | ||
| FROGGS | *g* | ||
| tadzik | nice :) | ||
| FROGGS | hope you can find the source of all evil now :o) | ||
| brrt | i'll have a much better chance now | 13:27 | |
| timotimo | hooray for friendship! | ||
|
13:27
oetiker joined
|
|||
| tadzik | it's magpi | 13:29 | |
| magic * | |||
| jnthn | .oO( The magpi, a bird that steals 3.14159265359 shiny things ) |
13:32 | |
| brrt can repeat the issue, not yet fix it | 13:37 | ||
| whut, it works | 13:47 | ||
| jnthn | whut whut \o/ | ||
| timotimo | holy yay! | 13:48 | |
| jnthn | brrt++ | ||
| brrt | FROGGS++ :-) | ||
| FROGGS | \o/ | 13:54 | |
| dalek | arVM/moar-jit: d59f69b | (Bart Wiegmans)++ | src/jit/ (3 files): Initialize global labels prior to dasm setup. This fixes an issue whereby dasm memory and by extension machine code would be corrupted. FROGGS++ for finding the root cause. |
||
| jnthn | Now there's just a few more ops to do. ;-) | 13:56 | |
| brrt | this.. makes the addition part of our magic frame work :-) | ||
| jnthn | \o/ | ||
| brrt | and return, etc | ||
| but like you said | |||
| just a few more ops :-D | |||
| 638 - 4 = 634 | 13:57 | ||
| jnthn | Well, can be strategic :) | ||
| brrt | by ops, I'm 0.75% done :-) | ||
| jnthn | sp_getarg_* could be good next ones. :) | ||
| brrt | yes | ||
| arithmetic ops, too | |||
| jnthn | Those are the optimzied ones, but provided you call it with the right types, it's all good. | ||
| Aye. :) | 13:58 | ||
| brrt | (those are easy) | ||
| jnthn | Yeah | ||
| FROGGS | what does that mean exactly? does the operation that results in the value 4 really ends up as machine code? | ||
| brrt | yes | ||
| if all is correct , you'll get a file called 'jitcode.bin' in your pwd? | |||
| that is the code that is called | |||
| FROGGS | \o/ \o/ \o/ | 13:59 | |
| -rw-r--r-- 1 froggs froggs 93 Jun 12 15:23 jit-code.bin | |||
| brrt | ok, you can dump that with the line i posted | ||
| objdump -b binary -D -m i386:x86-64 -M intel jit-code.bin | 14:00 | ||
| FROGGS | yes, I see.... things there | ||
| brrt++ # fast things | |||
| here is the dump: gist.github.com/FROGGS/00cc9c2b4c1443f4f613 | 14:01 | ||
| brrt | (the -M intel is for intel syntax, you can drop it for AT&T syntax, which some people prefer) | ||
| i.e. I'd prefer it if I weren't forced to write intel syntax all day :-) | |||
| FROGGS | hehe, I can't read any of them :o) | ||
| brrt | that's not my most-recent checkout, right? | 14:02 | |
| FROGGS | not, that is the one from the valgrind run | 14:03 | |
| brrt | using valgrind made it correct, too | ||
| funny | |||
| anyway, i can guide you through it if you care? | |||
| FROGGS | yes, running stuff in gdb or valgrind sometimes makes things work | ||
| the instructions? | 14:04 | ||
| I updated: gist.github.com/FROGGS/00cc9c2b4c1443f4f613 | |||
| brrt | I'll comment on your gist, how about that :-) | 14:05 | |
| FROGGS | +1 | ||
| :o) | |||
| awesome! | |||
| timotimo | linenoise is kinda stupid with regards to utf8 input and backspace :( | 14:10 | |
| > sļæ½ay %h | |||
| ===SORRY!=== | |||
| Malformed UTF-8 at line 1 col 2 | |||
| nwc10 | oh. :-( | ||
| that's LTA | |||
| timotimo | i typo'd an umlaut after s, then backspaced over it and wrote ay %h instead | 14:11 | |
| jnthn | timotimo: It's possible to pass an arg to MoarVM's configure to build yourself one with readline instead. | ||
| timotimo | mh | 14:21 | |
| brrt | there you go | 14:46 | |
| brrt is off for household chores | |||
|
14:46
brrt left
16:12
lizmat joined
16:14
woolfy joined
17:08
raiph joined
|
|||
| raiph | Did I just see bart get a 1 + 1 or similar to correctly moar-jit ? | 17:10 | |
| lizmat | not sure.. it went by so fast :-) | 17:11 | |
| raiph | :P | 17:13 | |
| jnthn | raiph: Yes, pretty much | 17:14 | |
|
17:20
woolfy left
17:33
jnap1 joined
|
|||
| nebuchadnezzar | is the moarvm build system specific or does it follow some conventions? | 17:39 | |
| FROGGS | I don't think it follows conventions yet | 17:43 | |
|
17:43
cognominal joined
|
|||
| nebuchadnezzar | I'm dumping %config to understand what is what ;-) | 17:46 | |
|
19:05
_sri joined
21:13
lizmat joined
22:14
lizmat joined
|
|||
| dalek | arVM/inline: 34dcc20 | jnthn++ | src/spesh/ (3 files): Don't inline recursive things or incomplete spesh. Includes adding an assert suggested by nwc10++. |
22:31 | |
|
22:32
woolfy joined
|
|||
| jnthn | nwc10: 34dcc20 should hopefully fix the other thing ASAN/Valgrind caught. | 22:32 | |
| nwc10: Verification of that (and knowing any other failures) would be very welcome :) | 22:33 | ||
| timotimo | jnthn: now implementing the method ann for QAST nodes | ||
| jnthn | :) | 22:34 | |
| brrt: On Windows, the maor-jit branch in Configure says "JIT isn't supported on MSWin32-x64-multi-thread yet." | |||
| timotimo | an idea how much that ought to save? | 22:35 | |
| jnthn | timotimo: Not sure off hand but allocating the hash lazily will save a lot of hashes | 22:36 | |
| dalek | arVM/moar-jit: f939d2c | jnthn++ | Configure.pl: Make JIT probe recognize Win32 x64. |
22:38 | |
| lizmat | perl5's approach: | 22:44 | |
| timotimo | mhm | ||
| lizmat | $ perl -MData::Dumper -E 'my %h; $h{a}=\%h; say Dumper(\%h)' | ||
| $VAR1 = { | |||
| 'a' => $VAR1 | |||
| }; | |||
| oops, ww | |||
| jnthn | brrt: The moar-jit build fails on MSVC with gist.github.com/jnthn/8a67ca154313a9dc6163 - it seems unhappy in a couple of ways. | ||
| brrt: I'll leave it with you, unless you can't figure it and want me to look deeper at it. | 22:45 | ||
| timotimo | jnthn: how performant is the "associative_delegate" trait in nqp? | 23:01 | |
| jnthn: what should i do if someone calls .hash on a QAST::Node; should that create the hash? | 23:06 | ||
| jnthn | timotimo: associative_delegate is a blessing and a curse | 23:08 | |
| timotimo: It makes the access very fast | |||
| timotimo: But it forces up-front allocation of the hash. | |||
| timotimo | aye. | ||
| i can't get a delegate in place after the annotation has been mixed in, right? | |||
| jnthn | Well, I'm not sure allowing <...> to magically work after the first .ann call is good API design. | 23:09 | |
| The history of QAST nodes is that they were once basically capture-like things and inherited from NQPCapture. | |||
| The .list nature for the children still makes sense, but I kinda see the hash nature of it being annotations as being a kind of hangover... | 23:10 | ||
| timotimo | ah, of course. | ||
|
23:18
woolfy left
|
|||
| timotimo | so much work ... | 23:34 | |
| fortunately i have a talk to prepare, so this counts as valid procrastination :) | 23:35 | ||
| sadly, now i'm running into a compile-time error that's neither "this type doesn't support associative operations" nor "the LHS of bind must be a n NQP::Var" | 23:42 | ||
| timotimo has run into a NPE on jvm, null object on moarvm etc ... | 23:49 | ||
| somehow, in method trait_mod:<is>, the block_ast annotation turns out to be null :\ | 23:51 | ||
| but it seems like i've changed all mentions of block_ast to use the .ann method already | |||
| turns out i never correctly set these annotations in the firs tplace %) | 23:53 | ||