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