Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-28

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

All times shown according to UTC.

Time Nick Message
00:01 cognome joined #moarvm
00:03 cognome_ joined #moarvm
00:25 cognome joined #moarvm
01:04 FROGGS_ joined #moarvm
01:25 cognome joined #moarvm
01:51 lizmat joined #moarvm
02:05 lizmat_ joined #moarvm
02:24 itz joined #moarvm
02:25 cognome joined #moarvm
03:25 ventica2 joined #moarvm
03:25 cognome joined #moarvm
04:02 njm joined #moarvm
04:03 njm left #moarvm
04:25 cognome joined #moarvm
05:23 ventica joined #moarvm
05:25 cognome joined #moarvm
05:42 woolfy joined #moarvm
05:52 ventica2 joined #moarvm
06:19 sergot hi o/
06:21 woolfy left #moarvm
06:25 cognome joined #moarvm
06:35 FROGGS[mobile] joined #moarvm
07:31 jimmyz joined #moarvm
07:31 * jimmyz can't build rakudo: Error while compiling op p6bool (source text: "nqp::p6bool(1)"): Cannot find method 'mast_compunit'
07:34 FROGGS ohh, then I won't upgrade until jnthn appears :o)
07:36 TimToady I just compiled with master moar and master nqp
07:36 TimToady maybe a version bump is needed?
07:37 * nwc10 has just built Rakudo
07:37 nwc10 with master/master/nom
07:38 FROGGS hmmm, the nqp revision looks good
07:38 FROGGS NQP_REVISION is one commit better than the mast_compunit introduction
07:39 jimmyz joined #moarvm
07:39 jimmyz sorry, I didn't git pull nqp ..
07:40 FROGGS jimmyz: np
07:40 nwc10 jimmyz: seems that you have identified a missing version bump needed
07:40 FROGGS jimmyz: have you reconfigures rakudo at all?
07:41 nwc10 oops, let me rephrase that more accurately - identifed that there is a version bump missing.
07:41 FROGGS because invoking 'make m-install' does not care about NQP_REVISION, only Configure.pl does
07:44 jimmyz yes, now rakudo builds  fine
07:45 jimmyz Stage parse is 44s vs 42s, and Stage mast 16s vs 14s
07:45 jimmyz 2s lower
07:46 nwc10 2s improvement since (roughly) which revision?
07:48 jimmyz since yesterday
07:49 nwc10 nice
07:49 nwc10 we need more weekends
07:57 zakharyas joined #moarvm
08:05 jimmyz yeah
08:25 Ven joined #moarvm
08:35 FROGGS_ joined #moarvm
08:39 jnthn Well, 4s total improvement there :)
08:40 nwc10 at this rate parse time will be negative within a few months
08:40 timotimo jnthn: sadly, lizmat isn't so lucky with the spectest timings :(
08:40 FROGGS_ uhh, how negative
08:41 nwc10 joke alert!
08:41 FROGGS_ timotimo: well, there was also the thing that fixes the wrap.t
08:41 FROGGS_ perhaps that was costly? I dunno
08:41 timotimo it seems like the timing that is faster also does more tests
08:41 timotimo which is weird
08:41 FROGGS_ O.o
08:45 jnthn odd
08:46 jnthn My spectest time here is the lowest I've had in a while.
08:46 timotimo strange indeed.
08:46 timotimo are you willing to tell us your short-term plans? :)
08:47 jimmyz esc?
08:47 jimmyz :P
08:48 timotimo well, yeah, but it seems like that's more or less a mid-term thing
08:49 jnthn Well, the things on this month's roadmap for Moar in part.
08:49 jnthn Also planning some things that I hope will improve startup time
08:50 timotimo "rewrite throws into gotos where possible" is still in front of us, right? as part of the handlers optimization
08:50 nwc10 Any more bloggage? or is coding more fun?
08:51 jnthn timotimo: Yeah
08:51 timotimo code-gen on tight code is going to be *so* *good* :)
08:51 timotimo well, if you consider spesh a part of code-gen, which i do
08:52 jnthn nwc10: Will try and post in the next week or so, once I've got more improvements done :)
08:54 nwc10 OMG MOAR improvments. How will we handle the awesome?
08:54 timotimo well~
08:54 timotimo we are still kind of behind other language's runtimes
08:55 timotimo when the jit lands, we'll have something only few dynamic language runtimes have outside of the javascript world
09:15 harrow joined #moarvm
09:25 jnthn m: say so not True
09:25 camelia rakudo-moar 319a78: OUTPUT«False␤»
09:26 brrt joined #moarvm
09:26 brrt \o
09:26 jnthn brrt \o/
09:26 timotimo brrt! :)
09:26 brrt jnthn: how do you debug stuff on windows
09:26 brrt :-)
09:26 brrt still alive
09:27 jnthn brrt: Using the VS debugger usually
09:27 jnthn brrt: There are a few tricks...
09:27 jnthn Configure with --debug is one of them
09:27 jnthn Unfortunately, it's silly enough to overwrite the moar.dll PDB with the moar.exe one
09:28 jnthn I typically hack the Makefile so the link line for moar.dll also has /pdb:$@.pdb
09:28 brrt that explains a bit
09:28 jnthn So it spits out moar.dll.pdb for that.
09:28 jimmyz it'll be nice if pdb info is in --debug on windows
09:28 jnthn The other thing is that --debug leaves the optimize flags in.
09:28 jnthn Which can be OK, but loses some locals.
09:29 jnthn If that's in your way, hunt down /Ox /GL in the compiler flags, and /LTCG in the linker flags, and remove them.
09:29 brrt that's no problem for me, i have the same 'issue' with gdb
09:29 jnthn Important: if you remove /GL be sure to remove /LTCG too - or the linker SEGVs...or at least the version I have does :D
09:30 brrt my point is i need to instruction-step through the jit compiled frame, so i need to break into MVM_jit_enter_code
09:30 brrt and... i can't manage that, but now i know why
09:30 jnthn ok :)
09:32 zakharyas joined #moarvm
09:38 brrt do you happen to know a good irc client for windows?
09:38 Ven .oO(webchat.freenode.net)
09:38 jimmyz chatzilla, mirc ...
09:38 Ven .oO(mirc, you'll love the remotes)
09:38 jnthn No; I use screen + irssi running on a Linux box and just SSH into it.
09:38 jnthn That's why I'm always here :)
09:39 Ven bnc!
09:39 jimmyz my linode box is down, that's why I'm not always here :(
09:40 brrt it seems i have the reverse setup from jnthn then :-)
09:40 brrt ok, pidgin it'll have to be then
09:41 * brrt bbiab
09:41 brrt left #moarvm
09:43 brrt_ joined #moarvm
09:43 timotimo brrt ssh's into his windows machine to irc?
09:44 brrt_ no, i virtualbox into a windows machine
09:44 brrt_ well, there's a moar.dll.pdb file now
09:44 brrt_ let's hope that gives me some actual symbols
09:46 FROGGS_ ... or prince
10:00 timotimo brrt_: jit compilation has its goas set as 2014.08 on moarvm.org; how do you feel about that? :)
10:05 brrt_ uh... well... good question
10:05 brrt_ i think i'm going to evade that answer only slightly and argue that a compiler is a 'lifetime of work' :-)
10:05 timotimo no pressure, html is rw on our server :)
10:06 brrt_ basically, i really want to have merged by then
10:06 jnthn Me too
10:06 brrt_ so that will give us at least the current JIT capacity; and hopefully also extops, and throws
10:07 jnthn Once brrt++ has JIT working on Windows, I'm planning to tinker a bit too. Provided brrt++ doesn't mind. :)
10:07 brrt_ probably extops, if jnthn++ has added the invokish flags to the extops already
10:07 * brrt_ doesn't mind at all :-)
10:07 timotimo i think he already has
10:07 jnthn brrt_: I haven't, but I've added a flags mechanism for ext ops, so it should be a 10 minute patch.
10:08 jnthn (the invokish indicator on ops ain't in master, so I couldn't do that bit)
10:08 timotimo oh
10:08 timotimo did they end up in esc?
10:08 jnthn No, they're in moar-jit
10:10 timotimo oh, ok
10:10 timotimo merge master into moar-jit and cherry-pick that commit into master? :)
10:14 jnthn Or just wait until we merge moar-jit :P
10:15 timotimo or that
10:16 * brrt_ hopes we can merge moar-jit after the ABI bugs are fixed?
10:17 jnthn I guess if we leave --enable-jit needed for Configure then it'll be relatively harmless.
10:17 jnthn The bigger decision is not actually the merge, but making that the default.
10:18 brrt_ ...a haaaaah
10:18 brrt_ ok, one bug found
10:23 brrt_ right, for compiling lua, one actually needs mingw
10:23 brrt_ much fun, right?
10:24 timotimo :S
10:24 brrt_ to compile luajit, you can't actually use windows nmake, becausee the makefile is too funky
10:24 jnthn brrt_: I found binaries somewhere...
10:25 jnthn http://sourceforge.net/p/safelua/wiki/LuaJIT%20binaries/ for example
10:25 brrt_ yep, have them too :-)
10:27 jnthn https://github.com/malkia/ufo seems another source of binaries
10:49 masak ufo? what a weird and random name for a project.
10:54 timotimo %)
10:55 brt joined #moarvm
10:58 brrt_ well, what do you know, can't build bitop without lua.h or luaconf.h
10:59 jnthn Oh
10:59 nwc10 brrt_: you're aware that ASAN doesn't like the JIT? http://paste.scsys.co.uk/410320
10:59 jnthn I thought the one I had included bitop...
10:59 colomon joined #moarvm
11:02 jnthn Maybe my one was actually from http://www.scilua.org/get.html
11:08 brrt_ nwc10: that actually seems a false positive
11:08 brrt_ tnx jnthn :-) i'll try that one
11:09 nwc10 brrt_: if so, it would be the first false positive I've ever seen ASAN report
11:09 nwc10 are you assuming something about the layout of memory in C arrays that ASAN doesn't want you to assume?
11:13 jnthn I think it's a real bug
11:14 jnthn MVM_OP_flip does:
11:14 jnthn MVMJitCallArg args[] = { { MVM_JIT_INTERP_VAR, MVM_JIT_INTERP_TC },
11:14 jnthn { MVM_JIT_REG_VAL, src } };
11:14 jnthn That's 2 args
11:14 jnthn Then:
11:14 jnthn jgb_append_call_c(tc, jgb, op_to_func(tc, op), 3, args, rv_mode, dst);
11:14 jnthn Where 3 is the arg count
11:19 brrt_ yes, that's a bug
11:19 brrt_ but that's not what ASAN finds
11:19 jnthn Oh?
11:19 brrt_ in fact, i removed that, and it still happened
11:19 jnthn Hm, I found that by looking at the lines ASAN was reporting
11:19 brrt_ i've struggled with that one for a bit already
11:20 brrt_ well, i'll change it anyway
11:20 cognome joined #moarvm
11:22 cognome_ joined #moarvm
11:25 brrt_ oh, great news folks, nmake only understands $< as a dependency
11:25 brrt_ much amaze huh
11:28 timotimo can has an up to date bail log statistic for my weekly?
11:29 timotimo sadly cant build mvm on my phone easily :)
11:29 moritz timotimo: how do I generate one?
11:33 timotimo MVM_JIT_LOG blah.txt and theb grep BAIL pipe sort pipe uniq -c pipe sort -n
11:33 timotimo for the setting compilation usually
11:34 brrt_ MVM_JIT_LOG is the environment variable
11:34 moritz mlenz@mlenz-workstation:~/p6/MoarVM$ git grep MVM_JIT_LOG|wc -l
11:34 moritz 0
11:35 moritz do I need a special branch, or something?
11:35 timotimo phone keyboard not excellent for irc
11:35 timotimo yes, moar-jit
11:35 timotimo and --enable-jit
11:35 timotimo but
11:35 timotimo for latest nqp, merge master, too
11:36 timotimo moarvm master
11:36 moritz eeks, that gives me conflicts
11:37 timotimo damn
11:37 brrt_ wait
11:37 brrt_ i'll get you a file
11:37 moritz I think I know how to resolve it
11:38 moritz does NQP need a branch too?
11:41 hoelzro moarning #moarvm
11:42 dalek MoarVM/moar-jit: 7d70cb7 | (Bart Wiegmans)++ | src/jit/ (4 files):
11:42 dalek MoarVM/moar-jit: Don't always write 4 arguments if we have fewer
11:42 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7d70cb7a27
11:42 brrt_ no, nqp should just run master
11:44 moritz ok, running the command now
11:44 timotimo who reported these memory leaks in moarvm recently?
11:46 FROGGS_ timotimo: TimToady
11:46 FROGGS_ in his palindrome RC example
11:47 moritz timotimo: http://perlpunks.de/paste/show/53d6384a.5ff2.12a
11:48 jnthn brrt_: Was that the Win32 ABI-bustying bug?
11:48 jnthn *busting
11:48 brrt_ jnthn: that seems to fix it for me, yes
11:48 timotimo thank you, moritz
11:49 timotimo elems should be very easy to impl
11:49 * moritz thought so too
11:49 timotimo sp_findmeth a bit more difficult perhaps
11:49 moritz not_i should be easy too
11:49 timotimo aye
11:49 brrt_ sp_findmeth is really painish
11:49 jnthn brrt_: Will do a build here
11:49 moritz chars, eq_n, ne_n
11:49 moritz no idea bout unbox_s
11:50 timotimo clone probably as well
11:50 jnthn brrt_: I'd just factor sp_findmeth out into a function and call it...
11:50 timotimo unbox_s can get a helper in reprconv
11:50 timotimo thatd be easy
11:50 brrt_ that, or try to do the cached versions first
11:50 jnthn brrt_: Unless you want to do the cache check outside and then delegate.
11:51 brrt_ right :-)
11:51 jnthn brrt_: Can we merge master into moar-jit?
11:51 brrt_ will do
11:51 jnthn Otherwise not sure I can build with latest NQP...
11:51 jnthn Thanks
11:53 dalek Heuristic branch merge: pushed 27 commits to MoarVM/moar-jit by bdw
11:53 brrt_ done
11:53 timotimo moritz, the most interesting part of implementing something with many bails in spesh is using grep and context numbers to find out what ops usually come after the op you just implemented
11:53 * brrt_ is reaaaaaally anxious
11:53 brrt_ also, the Makefile is really a huge pain for windows
11:54 brrt_ we / i should fix that some day
11:54 brrt_ i.e., the /pdb: flag
11:54 brrt_ and, the lack of $< in command lines
11:54 brrt_ etc etc etc
11:54 jnthn Yeah, it's nearly hit my "I should fix this" annoyance level
11:55 brrt_ it may be my own lack of familiarity for windows, but it hits my annoyance level daily
11:55 brrt_ with windows
11:55 timotimo heh
11:58 jnthn brrt_: NQP now builds and tests fine with moar-jit branch
11:58 jnthn Sadly, Rakudo setting build SEGVs
11:59 brrt_ i'm not out of the forest yet
11:59 brrt_ :'-(
11:59 jnthn No, but given it SEGV'd right at the start of the NQP build before, this is a big step forward.
12:00 nwc10 ASAN built MoarVM JIT is currently running tests
12:00 nwc10 that is progress
12:00 nwc10 er, NQP tests
12:00 hoelzro I think I found a Moar bug
12:00 hoelzro https://gist.github.com/hoelzro/2c02a2b7810aca50b195
12:01 hoelzro with MoarVM = 2014.07-34-g0513b67, rakudo = 2014.07-56-gfd2b197, this prints out the first 10 callframes and then complains about a NULL string
12:01 hoelzro I dug into it a little bit last night, and I noticed that a GC collection is happening right before then
12:01 brrt_ it also means that the bugs are that much harder to catch
12:01 hoelzro so I'm guessing that something with the GC and call frames is screwy
12:02 jnthn Unlikely
12:02 nwc10 brrt_: NQP tests all pass for MoarVM built with ASAN and JIT (unless I screwed up badly)
12:02 brrt_ \o/
12:02 nwc10 fails at /usr/local/bin/perl tools/build/gen-cat.pl moar src/Perl6/Metamodel/Archetypes.nqp src/Perl6/Metamodel/Naming.nqp src/Perl6/Metamodel/Documenting.nqp src/Perl6/Metamodel/Stashing.nqp src/Perl6/Metamodel/Versioning.nqp src/Perl6/Metamodel/TypePretense.nqp src/Perl6/Metamodel/MethodDelegation.nqp src/Perl6/Metamodel/BoolificationProtocol.nqp src/Perl6/Metamodel/PackageHOW.nqp src/Perl6/Metamodel/Modges/nqp/lib/QAST.moarvm:as_mast:4294967295)
12:03 jnthn hoelzro: I'd guess it may inline something and then fail to undo that when annotations wants its data
12:03 nwc10 but that's not an ASAN failure
12:03 brrt_ hmmm
12:03 timotimo froggs why did we go back to enumcharlist on moar again? are we using charring by now?
12:03 brrt_ that's weird
12:03 brrt_ if i see that line correctly, it's a perl script that fails?
12:04 hoelzro jnthn: do you have any suggestions on ways I can help confirm that?
12:04 hoelzro like some sort of runtime options that I can toggle?
12:04 timotimo rob, there is a environment variable to turn off inlining
12:05 jnthn hoelzro: set MVM_SPESH_INLINE_DISABLE=1
12:05 hoelzro that breaks too =(
12:05 jnthn Well, there's that hypothesis gone then :(
12:06 hoelzro oh well, now we know
12:09 hoelzro the GC code is a bit daunting to me
12:09 nwc10 hoelzro: hopefuly only a "bit" - it's not like it's parrot's GC
12:10 hoelzro but I wonder if maybe some object is being created in MVM_exception_backtrace that's not being added as a reference properly or something
12:10 hoelzro nwc10: I managed to figure out where things were getting called, so it can't be that bad =)
12:11 hoelzro I was looking late last night, so I can give it another go after I've rested and had coffee
12:13 FROGGS_ hoelzro: interestingly we had a bug like a week ago that showed up when compiling a TTIAR
12:13 FROGGS_ maybe it is just hidden but still there....
12:14 hoelzro ttiar?
12:14 FROGGS_ two terms in a row
12:14 jnthn No, that one was certainly fixed...this must be something else.
12:14 FROGGS_ ohh, good to know :o)
12:15 hoelzro ah ha
12:15 * brrt_ doesn't get a segv but a regular error
12:16 brrt_ worse yet, not even a JIT error
12:16 brrt_ :-)
12:16 brrt_ i probably have the wrong version of nqp
12:16 hoelzro oh, it *was* a segv, but then I played a little more to get more info and forgot to rename the file
12:16 jnthn brrt_: What is the error, ooc?
12:16 hoelzro I got the segv by doing "{caller.file}", iirc
12:17 hoelzro (not sure if brrt_ is referring to my error or not)
12:18 jnthn hoelzro: No, the error I ran into building Rakudo with moar-jit
12:18 hoelzro ah ha
12:19 brrt_ jnthn: fixed by updating nqp :-)
12:20 cognome joined #moarvm
12:21 * brrt_ afk
12:21 hoelzro if it's alright with everyone here, I'll file a Moar bug
12:21 jnthn hoelzro: Sure
12:28 cognome joined #moarvm
13:20 cognome joined #moarvm
13:40 jnap joined #moarvm
13:53 btyler joined #moarvm
14:18 lizmat joined #moarvm
14:20 cognome joined #moarvm
14:28 woolfy joined #moarvm
14:42 jnap joined #moarvm
14:44 woolfy left #moarvm
14:51 brrt joined #moarvm
14:52 brrt bad news; moar-jit wfm
14:52 brrt meaning that if it works for me, i don't know why it breaks for anyone else
14:52 brrt (on windows, even)
14:52 timotimo well, it's a good start that it does work
14:52 timotimo now you can get back to implementing cool stuff and someone else has to find the bug :D
14:52 brrt that may be so
14:53 brrt make sure y'all have clean versions of nqp and rakudo, and then it please report to me if it still breaks :-)
14:56 brrt as far as i can tell, there are a few high priority things to do
14:56 brrt a): the whole param_* stuff
14:57 brrt fwiw, i thought i /had/ chars, but apparantly not
14:57 brrt eq_n is funkier than it seems, too
14:58 jnthn oh?
14:59 brrt yes, i've inspected the gcc output, and there are two comparisons to make if you want to check two fp numbers for equality
14:59 [Coke] jnthn: I never did open a ticket on most recent segv; will try to remember to do so today.
14:59 brrt sp_findmeth is /really/ big, so i should do that next, i think
14:59 hoelzro brrt: is this regarding the segfault when building nqp?
14:59 brrt are you building nqp with moar-jit?
14:59 brrt on windows?
14:59 brrt then yes, otherwise no
15:00 timotimo brrt: should i do elems in the mean time?
15:00 brrt if you wish :-)
15:00 timotimo well, it ought to help, right? :)
15:00 jnthn brrt: Just done a debug build now
15:00 brrt does it work for you?
15:01 brrt (i always do debug builds, btw)
15:02 hoelzro I just noticed that my useful perl Configure.PL --prefix=/tmp/why --gen-moar --backends=moar hasn't been working today
15:02 hoelzro ...unless I check out a fresh copy of the rakudo repo
15:03 hoelzro it may be unrelated, but it sounded like what you all were talking about earlier
15:03 jnthn brrt: No, SEGV in CORE.setting build still :(
15:03 timotimo brrt: we have graphs_s and codes_s, but not chars :)
15:04 brrt that's weeeeird :-(
15:04 brrt on moar-jit/master/nom?
15:04 jnthn Yup
15:04 brrt with --debug?
15:04 * brrt doesn't get it at all
15:05 brrt i think your computer is just conspiring against me
15:05 jnthn Happens in MVM_multi_cache_find_callsite_args
15:05 brrt oh really?
15:05 jnthn Called from MVM_frame_find_invokee_multi_ok
15:05 brrt called from the JIT?
15:05 jnthn And then the stack claims to have a ton of frames
15:05 dalek MoarVM/moar-jit: 66bd7e4 | (Timo Paulssen)++ | src/jit/graph.c:
15:05 dalek MoarVM/moar-jit: chars is implemented the same as graphs_s for now.
15:05 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/66bd7e4848
15:05 jnthn Bottoming out in MVM_jit_enter_code
15:06 brrt hmmm
15:08 brrt ok, i know which fragment of code that is, so that's something
15:08 brrt (it's the slow invoke path)
15:09 brrt but it's weird that would break for you but not for me
15:10 jnthn aye
15:10 * brrt bbiab
15:10 timotimo brrt: how much testing should i do for my implementation of elmes before pushing?
15:10 timotimo elems*
15:11 timotimo oh, the core setting segfaults
15:11 timotimo isn't that fun
15:11 jnthn Darn. If I turn off optimization then it works.
15:11 jnthn Or is getting a load further
15:11 brrt :-o
15:13 timotimo well, all the elems i can see are followed by almost exactly the same code, culminating in an atpos_i that bails
15:14 timotimo and disabling the jit makes it work ... great ...
15:14 jnthn Yeah, it completed with JIT disabled
15:14 jnthn oops
15:14 jnthn with optimization disabled
15:15 jnthn (as in, C compiler opt)
15:15 timotimo oh?
15:15 timotimo i shall try that, too
15:15 timotimo where does your crash happen, ooc?
15:15 jnthn About a second into CORE.setting
15:16 timotimo mine happens a few frames down from jit enter code inside #0  0x00007f219e41b89d in MVM_multi_cache_find_callsite_args () from /home/timo/perl6/moarvm/../install/lib/libmoar.so
15:16 timotimo No locals.
15:16 timotimo #1  0x00007f219e3eb65a in MVM_frame_find_invokee_multi_ok () from /home/timo/perl6/moarvm/../install/lib/libmoar.so
15:16 timotimo No locals.
15:16 timotimo very early in stage parse
15:16 jnthn oh, that's exactly where mine is
15:16 jnthn Ah, so it happens on Linux too... :)
15:17 timotimo good to know
15:17 jnthn Oh, interesting...
15:18 timotimo i turned --optimize=0 and it still segfaulted
15:18 jnthn If I disable link time code generation and just do normal optimization without that it works
15:18 jnthn timotimo: I mean C compiler opt
15:18 timotimo yes, that's what i gave moarvm's configure.pl
15:18 timotimo this time the stack is much shorter
15:19 timotimo frame number 3 seems corrupted, as in: 0x0
15:20 cognome joined #moarvm
15:21 jnthn brrt: It's compiling with /GL and /LTCG that causes the explosion, it seems
15:21 timotimo this is bad news for me; how am i supposed to test my implementation?
15:22 timotimo jnthn: should i just push it and let you review it? it's kind of trivial, i believe
15:22 jnthn Well, push to a branch?
15:22 jnthn And test/merge it to moar-jit once it's possible to test it?
15:23 timotimo sure no problem
15:26 timotimo implemented atpos_i as well now.
15:27 timotimo i can at least use nqp as a little testbed
15:30 dalek MoarVM/jit-moar-ops: ed91447 | (Timo Paulssen)++ | src/jit/graph.c:
15:30 dalek MoarVM/jit-moar-ops: implement elems as call to MVM_repr_elems
15:30 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/ed91447106
15:30 dalek MoarVM/jit-moar-ops: c52948f | (Timo Paulssen)++ | src/jit/graph.c:
15:30 dalek MoarVM/jit-moar-ops: atpos_i is another hot op (implemented through MVM_repr_at_pos_i)
15:30 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/c52948f3b5
15:32 jnthn timotimo: iter is another hot one
15:32 jnthn Should just be a function call
15:32 jnthn And bindpos_o
15:32 jnthn bindkey_o too
15:33 jnthn And existskey
15:34 dalek MoarVM/jit-moar-ops: e8ab84c | (Timo Paulssen)++ | src/jit/graph.c:
15:34 dalek MoarVM/jit-moar-ops: push_i is next, unshift_i can have the very same code.
15:34 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/e8ab84ca77
15:36 timotimo i'm now following what happens with our parsing
15:37 jnthn I think we'll nail action methods and QAST construction a good bit before parsing.
15:37 timotimo the bails that used to be push_i are now indexat or eqat_s i think
15:38 timotimo sadly, indexat is a branchy instruction
15:41 timotimo doing iter next, then i'll look at if i can add branchy stuff without writing dasm files
15:41 timotimo hmm
15:41 colomon joined #moarvm
15:41 timotimo why is dst sometimes MVMint16 and sometimes MVMint32?
15:43 timotimo cool, eqat_s is non-branchy
15:46 timotimo all of the iterkey_s-used-to-bail are now iscclass bails; interesting
15:46 timotimo this is like chasing rabbits %)
15:51 timotimo hm, i didn't check, but it seems this execution dies earlier and earlier every time i add new instructions
15:51 timotimo could that be?
15:51 timotimo ah
15:51 timotimo well, now nqp segfaults, too
15:52 timotimo and really early :)
15:53 dalek MoarVM/jit-moar-ops: d22e36d | (Timo Paulssen)++ | src/jit/graph.c:
15:53 dalek MoarVM/jit-moar-ops: implement iter, iterkey_s and iterval
15:53 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/d22e36de34
15:53 dalek MoarVM/jit-moar-ops: 7227fca | (Timo Paulssen)++ | src/jit/graph.c:
15:53 dalek MoarVM/jit-moar-ops: implement bindpos_o and bindkey_o
15:53 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/7227fca497
15:54 timotimo ah, iterkey_s is Very Wrong
15:56 timotimo no, it was correct. strings being returned are handled via RV_PTR
15:57 timotimo now i don't know how to continue :\
16:00 timotimo i surely hope it's not my fault that things blow up everywhere now %)
16:01 timotimo it would be neato if brrt could implement not_i, ne_n and eq_n
16:03 timotimo i surely hope this is just a matter of the jit generating bad code under some circumstance and me just triggering that circumstance more often
16:03 timotimo or something like that
16:04 dalek MoarVM/jit-moar-ops: 71ab464 | (Timo Paulssen)++ | src/jit/graph.c:
16:04 dalek MoarVM/jit-moar-ops: shift_i and pop_i are very simple
16:04 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/71ab4648a3
16:05 [Coke] timotimo: what order are things in here: https://github.com/MoarVM/MoarVM/blob/71ab4648a31dcd0299be57de3acea09cb2109494/src/jit/graph.c#L111 ?
16:18 cognominal joined #moarvm
16:18 cognome joined #moarvm
16:50 japhb joined #moarvm
17:14 vendethiel joined #moarvm
17:16 * timotimo is back from places
17:17 timotimo nearly, but not really sorted by opcode value
17:17 timotimo :S
17:17 dalek MoarVM/jit-moar-ops: caa93e4 | (Timo Paulssen)++ | src/ (3 files):
17:17 dalek MoarVM/jit-moar-ops: getattr_i and eqat_s
17:17 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/caa93e4e68
17:22 Ven joined #moarvm
17:23 timotimo now i'm beginning to really miss brrt :\
17:39 dalek MoarVM/jit-moar-ops: ca03ffd | (Timo Paulssen)++ | src/jit/graph.c:
17:39 dalek MoarVM/jit-moar-ops: existskey is another common op.
17:39 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/ca03ffdae7
17:46 timotimo jnthn: can you look more closely at the box_[ins] instructions?
17:48 timotimo oh
17:48 timotimo they appear to be correct
17:48 timotimo i got confused with MVM_repr_box_* and MVM_box_*
17:51 dalek MoarVM/jit-moar-ops: 18fc43d | (Timo Paulssen)++ | src/jit/graph.c:
17:51 dalek MoarVM/jit-moar-ops: implement unbox_[ins]
17:51 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/18fc43d111
17:54 flussence Hi #moarvm, I'm hitting this error in some mundane perl6 code, any idea what might be causing it? https://github.com/MoarVM/MoarVM/blob/master/src/gc/collect.c#L421
17:55 flussence (I'm busy bisecting rakudo atm to figure out when it broke)
17:55 timotimo oh yikes
17:55 timotimo mundane meaning you're using neither multithreading nor asynchronous I/O?
17:56 zakharyas joined #moarvm
17:56 flussence I'm just open()ing some files and slurping their contents, nothing fancy... I did have threading code there but I stuck that codepath behind an env var because it doesn't work; it's running a plain loop and then errors out halfway through with that
17:57 jnthn That tends to indicate heap corruption
17:57 flussence (I wonder if there's some spooky action at a distance going on because the other code's still present-but-disabled)
17:58 jnthn It's more likely to be Moar that's interesting to bisect
17:58 flussence well if this bisect lands on one of the nqp revision changes, that'll help narrow it down still :)
17:59 jnthn True :)
18:06 timotimo jnthn: i'm looking into speshing objprimspec; the implementation checks if the first argument ("type") is null and if not, returns the storage_spec's boxed_primitive; does that mean i have to check for KNOWN_VALUE or would KNOWN_TYPE be enough? :S
18:06 timotimo i fear the former; which would make it useful much less often
18:06 timotimo except ... i could turn it into an isconcrete + multiply with the storage_spec of the known type %)
18:07 jnthn If you know the type I think you can do that
18:08 timotimo that == the isconcrete trick?
18:08 timotimo er, i think isnonnull
18:08 timotimo should be the answer
18:08 jnthn No, if you know the type you can actually call get_stroage_spec
18:08 jnthn And pull the value right out
18:08 jnthn And that'll be the answer
18:09 timotimo oh, if we know the type, that also means the thing wouldn't even be null
18:09 jnthn So it'll spesh to iconst_64_16 or so
18:09 timotimo gotcha :)
18:09 jnthn Right, we'd not have got that far; we'd have bust a gurad
18:09 timotimo oh, does that mean we can turn isnull/isnonnull into constants when we have a known type fact?
18:10 jnthn Hmm
18:10 jnthn Interesting question :)_
18:11 jnthn We may get a rather unintended consequence if we do that.
18:11 jnthn ah, though maybe not...
18:11 timotimo well, how come it's safe in the objprimspec case and not in the other? :)
18:13 jnthn I didn't mean it's unsafe
18:14 jnthn It's more that ifnonnull and isnull often show up in vivification-y situations
18:14 jnthn And you might end up introducing a guard that is going to get broken a lot.
18:14 timotimo oh, i didn't even look into how to mark guards as being used yet :\
18:15 timotimo but yes, that would be unhelpful
18:16 Ven joined #moarvm
18:16 jnthn At the moment we've very conservative
18:16 jnthn If you ask for the facts, it's marked as used
18:16 timotimo ah!
18:16 jnthn Can do better in the future
18:16 timotimo i'll just put a comment in there
18:23 timotimo for example, if we ended up not doing an optimization, we don't need to mark the guard "used"
18:23 timotimo is there perhaps a way to get a "forget i asked about this fact" thing? is the usage thing a counter?
18:24 jnthn No, not yet, but that's what we want
18:25 timotimo sounds almost like something i could implement, no?
18:27 FROGGS_ call it SvREFCNT_inc :o)
18:27 jnthn I'd probably rename the current thing get_and_use_facts and switch everything over, then add a get_facts and a use_facts, and then start updating things bit by bit
18:27 jnthn It's not actually a usage count
18:27 timotimo coerce string to int NYI - what.
18:28 jnthn Either a guard is used or it isn't
18:28 jnthn We don't care how many times
18:28 timotimo OK
18:28 timotimo ... how did i get that error message? o_O
18:29 timotimo oh, that's how
18:30 dalek MoarVM: f92fdd6 | (Timo Paulssen)++ | src/spesh/optimize.c:
18:30 dalek MoarVM: can do objprimspec at spesh-time
18:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f92fdd685b
18:30 dalek MoarVM: 587ca47 | (Timo Paulssen)++ | src/spesh/optimize.c:
18:30 dalek MoarVM: but please without debug spam.
18:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/587ca47c37
18:38 nwc10 brrt: ./perl6-m t/spec/S05-match/capturing-contexts.rakudo.moar fails with a spectest, but passes withut
18:38 nwc10 (I know that he's not here)
18:38 nwc10 the good news was that everything else passed. That's a JIT MoarVM built with ASAN
18:39 timotimo jnthn: should we - at some point - be able to only "use" a subset of the given facts and thus generate a less specific guard?
18:39 timotimo like: we have known_value, but we only care about known_type in this case?
18:40 jnthn known_value is never guarded anyway
18:41 jnthn it only happens for wval
18:41 jnthn or similar
18:41 jnthn We guard by type at most
18:41 timotimo OK
18:42 FROGGS_ nwc10: that are indeed good news
18:44 timotimo OK
18:48 timotimo working on the get/use split now
18:48 timotimo it'll require changes in rakudo/master, too, so ... hmm
18:53 timotimo should the "use_facts" function just take the MVMSpeshFacts structure again?
18:54 timotimo (and not the tc and g, especially)
18:54 jnthn Well, we always pass tc
18:54 jnthn Passing g may be wise
18:54 timotimo oh, i have to pass g either way
18:54 jnthn ah, good :)
18:55 timotimo so i can choose if i should pass the operand or the facts
18:55 jnthn Oh
18:55 jnthn Well, we have the facts, so may as well pass those I gues
18:55 jnthn *guess
18:55 timotimo aye. means less looky uppy action
18:58 timotimo jnthn: we often have a line like "get_fact(...)->usages--", in that case i can just get the fact without marking it used, correct?
18:58 jnthn Yeah.... get_facts_direct I think does that
18:59 timotimo aye, though i introduced a MVM_spesh_get_facts method you can use as part of the public interface
19:01 woosley joined #moarvm
19:18 brrt joined #moarvm
19:19 brrt \o
19:20 itz_ joined #moarvm
19:21 jnthn o/ brrt
19:21 * brrt sees all the excitement
19:22 timotimo hey brrt :)
19:22 timotimo i've made a bunch of ops for you, but moar-jit crashes really early even in an nqp build with my branch ;(
19:23 brrt ok, my guess is that compilation with link-time code generation changes the effective call conventions, because the compiler assumes that all will be ok since there are only a limited number of calls
19:23 brrt and you want me to debug it? :-)
19:24 timotimo oh
19:24 jnthn brrt: Hm, but I think timotimo++ got a similar crash...
19:24 timotimo do we have lto?
19:24 nwc10 brrt: (almost) "works on 'my' machine" - why bother with his? :-)
19:25 brrt i'll checkout out the moar-jit-ops branch, see if i can see what causes it
19:25 * brrt wants a 'gdb is my homeboy' shirt
19:25 jnthn timotimo: liquid titanium oil?
19:25 jnthn Oh, link time optimization...
19:26 jnthn Well, MSVC does
19:29 nwc10 I can't even build normally with LTO
19:29 nwc10 I get ./libmoar.so: undefined reference to `.L587'
19:29 nwc10 and a lot more like that
19:30 timotimo jnthn: in optimize_call there's a bunch of code that apparently used to do inlining above a call to spesh_inline, can that go?
19:31 timotimo also, there's an XXX about being able to remove a lookup of an enclosing code object or something
19:31 timotimo have no idea if it's a juicy target or not
19:31 itz joined #moarvm
19:32 jnthn brrt: See http://msdn.microsoft.com/en-us/library/xbf3tbeh.aspx
19:33 jnthn brrt: Of note, "When /LTCG is used to link modules compiled by using /Og, /O1, /O2, or /Ox, the following optimizations are performed:"
19:33 jnthn "Interprocedural register allocation (64-bit operating systems only)" is notable maybe
19:33 jnthn But "Custom calling convention (x86 only)" suggests it's not an issue for us
19:33 brrt hmmm
19:34 jnthn ooohhh
19:34 jnthn Para below is l'important.
19:34 timotimo doesn't explain the segfault on linux ;(
19:35 jnthn It may be doing similar opts...
19:36 brrt you mean: "If the compiler can identify all of the call sites of a function, the compiler ignores explicit calling-convention modifiers on a function and tries to optimize the function's calling convention:"
19:36 jnthn Right
19:37 brrt but /me brb, got an errand to run
19:37 brrt making the affected symbols public should alleviate if this is the case
19:40 dalek MoarVM/split_get_use_facts: 9d377a3 | (Timo Paulssen)++ | src/ (3 files):
19:40 dalek MoarVM/split_get_use_facts: split get_facts and use_facts from get_and_use_facts.
19:40 dalek MoarVM/split_get_use_facts: review: https://github.com/MoarVM/MoarVM/commit/9d377a3d6b
19:40 timotimo ^- looks sane?
19:41 Ven joined #moarvm
19:43 itz_ joined #moarvm
19:46 timotimo well, almost.
19:47 dalek MoarVM/split_get_use_facts: be8cfdf | (Timo Paulssen)++ | src/spesh/optimize.h:
19:47 dalek MoarVM/split_get_use_facts: fix teh build
19:47 dalek MoarVM/split_get_use_facts: review: https://github.com/MoarVM/MoarVM/commit/be8cfdf8f0
19:48 flussence well this is bizarre, that bisect I was doing... went to sleep. 0% cpu usage in the middle of compiling CORE.setting.
19:49 flussence oh well, it's narrowed it down to either rakudo f1fd505 or 41cd958, so that's a start.
19:53 flussence ...reproducible too. weird.
19:57 jnthn flussence: There was one commit that deadlocked setting comp once on non-Windows.
19:58 flussence oh, that'd be it :)
19:58 timotimo probably just noise; with the split_get_use_facts, stage parse might have been faster by 0.5s
19:59 timotimo yays
19:59 timotimo removed 15 guard ops throughout the whole core setting specialization :)
20:00 jnthn (I forgot libuv mutexes aren't portably reentrant)
20:00 timotimo 5x type and 10x conc
20:00 timotimo jnthn: would you like me to merge the branch? :)
20:01 jnthn timotimo: Gimme a bit to look at it; got 5 mins more $dayjob task to do then will be able to
20:01 flussence oh, looks like most of this bisect helped anyway: the breakage is between moar 0edddb3..684027b
20:01 flussence now to figure out how to bisect those...
20:02 timotimo :)
20:03 brrt joined #moarvm
20:04 * brrt back
20:04 timotimo heyo brrt :)
20:04 brrt ok, now have time for your bug
20:05 timotimo soon, a whole 15 guards less will be part of the setting compilation thanks to spesh!
20:05 timotimo it'd be kinda neat if we could track the number of bails per exact guard
20:05 timotimo (without impacting run time of the rest of the vm if we are not looking)
20:08 brrt ok, so i've traced the error to a MASTNode pointing to Not An Object
20:09 brrt i.e., a valid pointer, but very much not an object (thread id 0, st 0)
20:13 jnthn bbi10
20:21 brrt right, chars already presents a problem
20:22 timotimo huh?
20:22 timotimo it does? did i do it wrong? :(
20:25 brrt no
20:25 brrt the problem is apaprant before that, even
20:26 brrt but, at least this is a problem that doesn't appear in the compiler, so it's good for figureing out what hapepns
20:29 timotimo oke
20:30 timotimo sadly, i can't get an up-to-date bail log ;(
20:30 brrt i know
20:31 timotimo about 510 bails have been pushed forwards from moritz' last measurement
20:32 brrt ok, that's very nice
20:32 Ven joined #moarvm
20:35 lizmat joined #moarvm
20:37 brrt ok there's a speshbug in master that crept into moar-jit during the merge and /probably/hopefully/ explains why current moar-jit crashes
20:38 brrt (how do i know it's even a spesh bug? just because)
20:38 brrt i.e. it still happens in my foo.nqp test file despite having compiled a totally-free-of-jit version of moar
20:38 brrt the error is that 'this representation (P6Num cannot unbox to a native int)
20:38 brrt '
20:38 brrt now frankly i wonder why not
20:39 timotimo a num? to an int?
20:39 brrt yes
20:39 timotimo why does our code assume it's possible? =o
20:39 brrt it doesn't (usually), that's the bug
20:40 brrt it's not an inlining bug
20:40 timotimo P6num doesn't have a spesh function at least
20:40 timotimo neither does P6int
20:40 brrt so i'm wondering what changed between moar-jits last master merge and now
20:42 brrt i should /really/ get to writing a proper jit test suite
20:42 timotimo that seems like a good hint
20:43 brrt if that (coupled with param refactor, extops, and throwing) is /all/ i'll do for the next few weeks, i might as well be satisfied
20:43 brrt although i'll never be exactly that, of course
20:50 timotimo we still need extops to teach the jit how to jit them :S
20:50 timotimo otherwise perl6 code will never actually be jitted! :(
20:52 * jnthn back
20:52 FROGGS_ just in time I'd say...
20:53 timotimo that pun will get old fast
20:54 brrt jnthn has done a lot about that
20:54 brrt basically, with extops i can go two approaches
20:54 jnthn Hm, spesh bug?
20:54 brrt a): i assume they do anything and everything, so i check all relevvant variables afterwards (i.e. cur op, cur frame, perhaps more?) and fallout if necessary
20:55 jnthn How do I reproduce it?
20:55 timotimo i suppose it doesn't surprise that something involving unbox_n didn't get triggered in the core setting compilation or anywhere else in compiling rakudo or nqp ...
20:55 brrt git checkout moar-jit foo.nqp ; ./foo.nqp
20:55 timotimo nums is hardly something we'd use in the compiler, after all
20:55 brrt (from master or anywhere else)
20:55 * brrt nods
20:57 brrt you should see a 'can't unbox P6num to native int' error
20:58 jnthn Yeah, got it
20:59 jnthn phew, it's not inlining or OSR related though.
20:59 brrt :-)
21:00 brrt i see you've added interpreter support for 'invokish' extops
21:01 jnthn How on earth did that work before...
21:02 brrt i don't know, must've not happened often?
21:03 jnthn Oh...
21:03 jnthn args.c is more liberal than I realized
21:04 timotimo :D
21:04 timotimo seems like we found the culprit :)
21:04 brrt that's pretty fast :-o
21:04 timotimo that's jnthn for you
21:15 * brrt afk
21:16 brrt left #moarvm
21:48 timotimo seems like the patch is getting tested rigorously before being pushed into the 'net :)
21:52 jnthn Well, it seems to help, just that I'm looking into the JIT thing too
21:52 timotimo ah, OK
21:52 timotimo good to know
22:05 timotimo when jnthn has fixed the jit thing, too, brrt will be able to implement not_i, ne_n and eq_n and things will be so good! :3
22:10 jnthn grrr, this is a pain
22:14 timotimo i hope you'll persevere
22:14 * timotimo ducks
22:14 timotimo i only ever do the non-painful stuff %)
22:14 jnthn aha
22:14 timotimo oh, you only noticed that now? :P
22:15 jnthn no no :P
22:15 jnthn #if defined _MSC_VER
22:15 jnthn #  define MVM_USED_BY_JIT __pragma(optimize( "g", off ))
22:15 jnthn :)
22:15 jnthn this seems to help
22:15 timotimo can you intuit what the gcc-equivalent is?
22:15 timotimo also: oh man >_<
22:16 jnthn Not easily
22:16 timotimo we'll have to annotate every single function the jit will ever use
22:16 jnthn Yeah
22:16 timotimo i saw an attribute for gcc that meant something similar i think, let me look again
22:16 jnthn In theory this means I can keep ltcg for everything else, though.
22:18 timotimo externally_visible
22:18 jnthn I'd have guessed that corresponds to __dllspec(export) or so
22:18 jnthn Trouble is that didn't do it
22:18 jnthn Because MSVC just goes and uses funky calling convs and then *notes in the link .lib that it did so*!!!
22:19 timotimo ah, hm
22:19 timotimo This attribute, attached to a global variable or function, nullifies the effect of the -fwhole-program command-line option, so the object remains visible outside the current compilation unit.
22:19 jnthn So anything linking against it can join in the game :P
22:19 jnthn Hm
22:19 timotimo m)
22:19 jnthn "remains visible"
22:19 timotimo that's nice
22:19 timotimo yes, not the same i realize
22:19 jnthn Waht's -fwhole-program defined as?
22:25 timotimo Assume that the current compilation unit represents the whole
22:25 timotimo program being compiled.
22:25 timotimo totally useless for our purposes
22:26 timotimo i went through the whole function-attributes page of the gcc docs and found nothing
22:26 dalek MoarVM/moar-jit: fee2d64 | jnthn++ | src/ (2 files):
22:26 dalek MoarVM/moar-jit: Add MVM_USED_BY_JIT and add it in one place.
22:26 dalek MoarVM/moar-jit:
22:26 dalek MoarVM/moar-jit: This disables optimizations on a per-function basis that fiddle with
22:26 dalek MoarVM/moar-jit: calling conventions and so frustrate JIT compilation's calls to them.
22:26 dalek MoarVM/moar-jit: Only annotated the one that made things explosive on Windows so far,
22:26 dalek MoarVM/moar-jit: but really we should mark up all that the JIT uses.
22:26 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/fee2d64a15
22:26 timotimo in only one place?
22:26 jnthn A volunteer to add MVM_USED_BY_JIT elsewhere would be awesome... :)
22:27 jnthn (just means looking through src/jit/[x64_emit.dasc& graph.c] for &MVM_* and then finding them in the .c files and pre-pending the macro.
22:27 jnthn )
22:27 timotimo sounds like a great thing to automize m)
22:30 jnthn Go for it ;)
22:30 timotimo nope nope nope :3
22:34 dalek MoarVM: 35919a9 | jnthn++ | src/spesh/args.c:
22:34 dalek MoarVM: Do more checking before speshing arg unboxing.
22:34 dalek MoarVM:
22:34 dalek MoarVM: We could end up trying to unbox a num as an int before. While we can
22:34 dalek MoarVM: spesh that situation, for now just make sure we apply the transform
22:34 dalek MoarVM: when it really is safe.
22:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/35919a9ca1
22:36 timotimo i merged that into moar-jit and we still segfault; so i'll actually need to get something proper for the used_by_jit thingie?
22:36 timotimo :\
22:36 timotimo even with --optimize=0
22:36 timotimo though it just passes no -O option, so maybe -O1 is the default?
22:36 carlin did you know you can do --noo as a shortcut to --optimize=0? :D
22:38 timotimo noooooooo
22:38 dalek MoarVM/moar-jit: f92fdd6 | (Timo Paulssen)++ | src/spesh/optimize.c:
22:38 dalek MoarVM/moar-jit: can do objprimspec at spesh-time
22:38 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/f92fdd685b
22:38 dalek MoarVM/moar-jit: 587ca47 | (Timo Paulssen)++ | src/spesh/optimize.c:
22:38 dalek MoarVM/moar-jit: but please without debug spam.
22:38 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/587ca47c37
22:38 dalek MoarVM/moar-jit: 35919a9 | jnthn++ | src/spesh/args.c:
22:38 dalek MoarVM/moar-jit: Do more checking before speshing arg unboxing.
22:38 dalek MoarVM/moar-jit:
22:38 dalek MoarVM/moar-jit: We could end up trying to unbox a num as an int before. While we can
22:38 dalek MoarVM/moar-jit: spesh that situation, for now just make sure we apply the transform
22:38 dalek MoarVM/moar-jit: when it really is safe.
22:38 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/35919a9ca1
22:38 dalek MoarVM/moar-jit: b69bd55 | jnthn++ | src/spesh/ (2 files):
22:38 timotimo :3
22:38 jnthn timotimo: Hm, where do you get segfaults?
22:39 jnthn But yeah, perhaps
22:39 jnthn You could try the pragma you found
22:39 timotimo very early in the stage parse of core setting
22:39 timotimo but the pragma i found is almost certainly useless
22:41 timotimo how do i figure out what exactly is wrong? :\
22:41 jnthn Was it in the same place I had the problem?
22:42 jnthn MVM_frame_find_invokee_multi_ok?
22:42 timotimo i think so, let me get a fresh core dump
22:43 timotimo #0  0x00007fadbc1f6bc6 in MVM_multi_cache_find_callsite_args (tc=0x1c21600, cache_obj=0x7fadbb935cf8, cs=0x0,
22:43 timotimo https://gist.github.com/timo/65133b28e088277fe0f2
22:43 timotimo see how there's a 0x00 stack frame?
22:44 timotimo if cs->has_flattening blows up
22:44 timotimo so the cs pointer must be b0rken
22:44 timotimo oh, yeah, it's null
22:44 timotimo that's why
22:45 timotimo i just don't know why it's null :P
22:45 timotimo not really good at the assembly thingie
22:45 jnthn yes, that's the problem I had too
22:45 jnthn Before disacling that optimization for that function
22:46 timotimo which exact function is that?
22:46 timotimo you said you have find_invokee_multi_ok, i have multi_cache_find_callsite_args
22:46 timotimo oh
22:46 timotimo duh, it's one frame up
22:46 jnthn look donw a frame
22:46 jnthn or up :)
22:47 timotimo i look down on these frames
22:48 jnthn hah, I tried your JIT extra ops branch and omg segv :)
22:49 timotimo i wonder if that's due to more missing used_by_jit annotations or due to me messing stuff up ...
22:50 timotimo i explicitly gave moar's cflags a -fno-lto ...
22:51 timotimo so that's not it
22:51 jnthn Well, think I see a mistake
22:51 timotimo Beware that you must then declare the cdecl or regparm(0) attribute for a function that will follow standard GCC calling conventions. See C Extensions::Extended Asm:: section from the GCC info pages. See also how Linux defines its asmlinkage macro.
22:52 jnthn hah, and after fixing that it works
22:52 jnthn Mind that I merged moar-jit into your branch?
22:52 timotimo no problem
22:52 timotimo feel free to merge it back as well
22:52 timotimo or just merge it back and drop the local other-direction merge :)
22:52 timotimo and cherry-pick the fix etc etc
22:53 dalek MoarVM/jit-moar-ops: f92fdd6 | (Timo Paulssen)++ | src/spesh/optimize.c:
22:53 dalek MoarVM/jit-moar-ops: can do objprimspec at spesh-time
22:53 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/f92fdd685b
22:53 dalek MoarVM/jit-moar-ops: 587ca47 | (Timo Paulssen)++ | src/spesh/optimize.c:
22:53 dalek MoarVM/jit-moar-ops: but please without debug spam.
22:53 timotimo there is a -mrtd flag for gcc
22:53 timotimo does that seem familiar?
22:53 jnthn Not to me.
22:53 dalek joined #moarvm
22:54 dalek MoarVM/jit-moar-ops: 34d35ec | jnthn++ | src/jit/graph.c:
22:54 dalek MoarVM/jit-moar-ops: Correct an arg count.
22:54 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/34d35ec596
22:55 jnthn Taht fixes the SEGV, but unfortunately we now get a hang in NQPHLL.nqp compilation.
22:55 timotimo so ... do i want cdecl or stdcall?
22:55 timotimo d'oh
22:56 jnthn I guess cdecl
22:57 timotimo unfortunately -mrtd seems to force the opposite
22:58 brrt joined #moarvm
22:58 brrt yeah, if you could not steal the thunder of my awesome bugfixing commit that changed the arg count.. that'd be great
22:58 brrt i literally have the same commit ready to push :-D
22:58 jnthn ;-)
22:58 jnthn At least I fixed the Win32 thing
22:58 jnthn Do you get the hang in NQPHLL.nqp too?
22:59 brrt oh, awesome
22:59 brrt what hang? not yet i didn't
22:59 jnthn When I build NQP with 34d35ec it hangs
23:00 brrt i see
23:00 brrt weird
23:01 jnthn Doesn't with plain moar-jit
23:01 timotimo src/core/frame.c:1234:1: warning: ‘__cdecl__’ attribute ignored [-Wattributes]
23:01 jnthn So should be easy enough if nobody else can reprouduce it for me to go through the commits
23:01 brrt __cdecl__ isn't relevant in x64
23:01 timotimo brrt: well, how do i fix the segfault then? :(
23:01 timotimo i really want the jit to work
23:01 brrt which segfault?
23:02 * brrt confused
23:02 timotimo the segfault i've been constantly getting :)
23:02 brrt that one? git pull
23:02 timotimo https://gist.github.com/timo/65133b28e088277fe0f2
23:02 jnthn brrt: Before I added MVM_USED_BY_JIT I got the same SEGV as timotimo here on Windows.
23:02 brrt oh, that's the windows one
23:02 jnthn brrt: cs was invalid
23:02 brrt what? where do you get it?
23:02 brrt :-o
23:03 jnthn brrt: Since I added MVM_USED_BY_JIT it's gone on Windows
23:03 brrt that's weird...
23:03 jnthn I basically stopped LTCG going and doing...something...
23:03 brrt uhuh
23:03 jnthn But timotimo now has the same issue on...Linux with gcc I guess.
23:03 timotimo yes, linux with gcc
23:03 brrt i had expected it'd be necessary to make the symbol public, but this works
23:03 brrt but linux and gcc don't use LTO?
23:03 jnthn Yeah, I tried public first.
23:04 jnthn Well, thing is...I don't *know* that it's calling convention related.
23:04 jnthn What I disabled really are "global" optimizations
23:04 timotimo for now i have to run get a tram
23:04 * timotimo packs
23:05 brrt hmmmmm
23:05 jnthn http://msdn.microsoft.com/en-us/library/1yk3ydd7.aspx
23:05 * brrt wonders what version of gcc timotimo uses
23:06 brrt basically, it'd just be 'weird' if the callsite was all wrong like that
23:06 timotimo gcc (GCC) 4.8.3 20140624 (Red Hat 4.8.3-1)
23:06 brrt that's the same as i have
23:07 jnthn brrt: Yes, I'm wondering, given it seems to do register opts, if there's some weirdness going on with that...but I don't see where
23:07 jnthn It *is* strange we hit the same SEGV on two completely different compilers.
23:07 brrt i suppose you're using the register view?
23:07 jnthn No, I just wsa reading the thing I linked above
23:07 brrt yes, especially if it is in fact optimization related
23:08 brrt ok, i should do that too then
23:10 brrt although, first, i should probably repeat the crash
23:11 brrt why is gdb printing nqp source code at me?
23:11 jnthn o.O
23:12 brrt oh, because one of them is the argument to a string
23:13 timotimo i turned optimisations off for moarvm
23:16 brrt and what happened then?
23:17 timotimo the crash you see in the paste
23:17 jnthn Got a meeting in the morning...sleep time... o/
23:17 timotimo gnite jnthn
23:17 brrt \o
23:18 brrt ok, i'll do the same then
23:18 timotimo brrt fix my thing
23:18 timotimo nnnooooooooooooo
23:18 brrt what?
23:18 timotimo how am i supposed to sleep
23:18 brrt why shouldn't you be able to sleep?
23:18 timotimo can you at least give me a new jit log?
23:19 brrt sure, of what?
23:19 timotimo not knowing what is wrong will keep me up
23:19 timotimo core  setting would  be  nice
23:19 brrt :-)
23:19 brrt well, can't get there right now, because as jnthn++ so rightly said, moar-jit hangs on something
23:20 brrt 'something? what's something?'
23:20 brrt hell if i know
23:20 timotimo also... having a log of the compete compilation of everything, nqp and rakudo, would be interesting
23:20 brrt yes
23:20 timotimo then just build nqp without jit
23:20 timotimo and just the core setting with jit
23:20 timotimo :)
23:21 brrt i'll try :-)
23:21 timotimo cheat as much as you have to
23:21 timotimo yay
23:21 timotimo if you paste the whole log I can do more science to it
23:23 * brrt will do just that
23:23 timotimo a truncated log would be fine as well
23:23 timotimo if the core setting hangs as well
23:24 timotimo thx :)
23:24 brrt i'll have to see if that happens
23:26 timotimo I may write an analysis script for the jit log
23:27 brrt https://gist.github.com/bdw/9abb46e9e4a3d0bc2cc9
23:29 * brrt is now afk for real tonight
23:29 brrt left #moarvm
23:53 timotimo used to be 1588 bails (when moritz pasted his stuff) and now is 1149 in the truncated jit log
23:54 timotimo it's hard to tell if it'd be the same number if it weren't truncated ...

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