Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-15

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

All times shown according to UTC.

Time Nick Message
01:02 xiaomiao joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:02 FROGGS_ joined #moarvm
08:41 rurban joined #moarvm
08:58 kjs_ joined #moarvm
09:42 zakharyas joined #moarvm
11:37 kjs_ joined #moarvm
11:43 FROGGS_ okay, developing for mobile phones is a little bit unfun
11:44 FROGGS_ I can compile all deps for QNX except libuv (yet)
11:44 FROGGS_ but even if I could compile moarvm and nqp... I have no shell where I could test a one-liner
11:44 jnthn o.O
11:45 jnthn Yeah, sounds a bit unfun
11:45 FROGGS_ there are sample C apps where I would render text using OpenGL...
11:47 FROGGS_ but all in all sounds like too much work
11:48 jnthn yeah
11:48 FROGGS_ it might be more worthwhile to look at android
11:48 FROGGS_ though I guess one cant do much with C there
11:48 jnthn Especially when we don't have an OpenGL module yet, afaik?
11:48 FROGGS_ true
11:50 kjs_ joined #moarvm
11:51 jnthn ah, it seems we do tweak successors in the spesh graph on inlining
11:52 jnthn oh, heh. If we inline something but then determine the branch we inlined it into is dead, I guess we could hit this issue...
12:51 zakharyas joined #moarvm
12:55 dalek MoarVM/spesh-value-prop: f99aab5 | jnthn++ | src/spesh/graph.c:
12:55 dalek MoarVM/spesh-value-prop: For now, re-compute preds before dominance.
12:55 dalek MoarVM/spesh-value-prop:
12:55 dalek MoarVM/spesh-value-prop: Seems we might be getting our succ/pred out of sync in some of the
12:55 dalek MoarVM/spesh-value-prop: optimizations. Work around it for the moment.
12:55 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/f99aab5ece
12:55 dalek MoarVM/spesh-value-prop: bf1716e | jnthn++ | src/spesh/optimize.c:
12:55 dalek MoarVM/spesh-value-prop: Rename second_pass to value_propagation.
12:55 dalek MoarVM/spesh-value-prop:
12:55 dalek MoarVM/spesh-value-prop: It will gradually grow into a common pass for a number of related
12:55 dalek MoarVM/spesh-value-prop: optimizations.
12:55 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/bf1716e9d9
12:55 dalek MoarVM/spesh-value-prop: d7444cf | jnthn++ | src/spesh/optimize.c:
12:55 dalek MoarVM/spesh-value-prop: Re-organize and document optimization top-level.
12:58 dalek MoarVM/spesh-value-prop: 0161106 | jnthn++ | src/spesh/optimize.c:
12:58 dalek MoarVM/spesh-value-prop: Re-order code to match stage order.
12:58 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/016110657e
12:58 dalek MoarVM/spesh-value-prop: 84ff588 | jnthn++ | src/spesh/optimize.c:
12:58 dalek MoarVM/spesh-value-prop: First attempt at dominator re-computation.
12:58 dalek MoarVM/spesh-value-prop:
12:58 dalek MoarVM/spesh-value-prop: This also gets us using the graph.c version of BB elimination, and
12:58 dalek MoarVM/spesh-value-prop: trying to fix things up. Alas, it breaks a few things.
12:58 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/84ff58804b
13:26 dalek joined #moarvm
13:28 zakharyas1 joined #moarvm
16:27 nwc10 jnthn: yesterday, ASAN was happy with your new branch. Today, your new MoarVM branch SEGVs very early in the NQP build
16:27 nwc10 I assume that you knew this already.
16:28 jnthn It doesn't even pass NQP's make test with a ready built NQP
16:28 jnthn I didn't try and NQP build without working that bit out.
16:30 jnthn btw, everything except the final commit should be fine
16:31 jnthn That one got pushed 'cus I was leaving home for a week and wanted it somewhere so I can continue working.
16:32 FROGGS_ http://i.imgur.com/kaaYOwW.png :/
16:33 FROGGS_ though, it is nice to have a bash, binutils, make, git and an almost working perl on my tab...
16:36 jnthn aww
16:37 FROGGS_ I could attempt to cross compile it, but it would be nice to Just Do It on that machine
16:46 timotimo is there no ssh server for android? :)
16:52 flussence depends which rom you're using; CM has a pretty decent command line setup
16:53 flussence no gcc though, aww :(
16:54 FROGGS_ timotimo: there is
16:56 FROGGS_ I've used this: http://kevinboone.net/kbox2.html
16:56 FROGGS_ you dont have to root your device for this, which is nice
17:14 dalek MoarVM/spesh-value-prop: 660bcd8 | jnthn++ | src/spesh/deopt.c:
17:14 dalek MoarVM/spesh-value-prop: Fix deopt debugging aid; #define it out.
17:14 dalek MoarVM/spesh-value-prop:
17:14 dalek MoarVM/spesh-value-prop: Makes it easier to turn it on/off as needed.
17:14 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/660bcd88d0
17:16 nwc10 jnthn: yes, previous HEAD^ passes
17:20 jnthn nwc10: Ok, good to know
17:23 jnthn The last thing that happens before the test I have explodes is a missed JIT deopt idx
17:23 jnthn So something's rotten
17:30 kjs_ joined #moarvm
17:34 jnthn detrain &
17:48 [Coke] that was a pleasant surprise; went to test install of moarvm on another os x box and got a prebuilt binary
17:50 diakopter left #moarvm
17:52 timotimo so in theory we have CUnion, but it won't be merged until it gets tested on non-windows and non-linux boxes?
17:53 [Coke] I can run a test on osx …
17:54 timotimo that's what i was going to suggest if that was the major blocker
18:06 timotimo Invalid typename 'Poinder' in parameter declaration. Did you mean 'Pointer'?
18:13 [Coke] timotimo: what branch of which repo?
18:18 timotimo i don't know
18:21 kjs_ joined #moarvm
18:33 timotimo Lexical with name '$x' has a different type in this frame
18:33 timotimo hm ... how?
18:38 dalek Heuristic branch merge: pushed 59 commits to MoarVM/union by FROGGS
18:48 FROGGS_ [Coke]: you'd need MoarVM/union + nqp + rakudo/union (HEAD of all of them)
18:48 FROGGS_ timotimo: we also need the union support in the jvm backend before we can merge it
18:50 timotimo oh, damn
18:53 FROGGS_ should not be a big issue
19:16 dalek MoarVM: e39a7d7 | FROGGS++ | src/main.c:
19:16 dalek MoarVM: use new MVM_vm_set_* functions
19:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e39a7d7717
19:38 nwc10 FROGGS_: you are making little endian assumptions in the union test in your branch: http://paste.scsys.co.uk/469453
19:39 FROGGS_ hmmmm...
19:39 nwc10 I'm not sure what would be the cleanest way to make it work and test the stuff you're trying to test, without getting it to look ugly and complex
19:39 FROGGS_ yeah
19:39 nwc10 also, I'm suprised that the "char in union" tests aren't failing too
19:53 dalek MoarVM/cpp2: 6345e59 | FROGGS++ | / (8 files):
19:53 dalek MoarVM/cpp2: reapply all commits for C++ support
19:53 dalek MoarVM/cpp2: review: https://github.com/MoarVM/MoarVM/commit/6345e59ed4
19:53 FROGGS_ the cpp branch seems unmergable... for some reason
19:54 FROGGS_ now let's think about unions on BE
20:03 FROGGS_ m: say (1 +< 30).fmt('%#b')
20:03 camelia rakudo-moar 1fdb76: OUTPUT«0b1000000000000000000000000000000␤»
20:03 FROGGS_ ahh, of course char works accidently
20:05 FROGGS_ m: say 1 +< 30 +> 24 == 1 +< 6 # because
20:05 camelia rakudo-moar 1fdb76: OUTPUT«True␤»
20:06 FROGGS_ so I did not choose my test cases carefully enough :o)
20:08 FROGGS_ I guess a long|char union is not portable between LE and BE when it is used to 'cast' from long to char and vice versa
20:09 FROGGS_ so the Perl 6 tests should probably just test if $union.i returns what we have written via C to the char "slot"
20:17 FROGGS_ or we calculate an offset for members of a union that are smaller than the union itself?
20:21 nwc10 I'm not hugely awake, and I'm not sure either
20:24 FROGGS_ np, I am just thinking loudly :o)
20:37 pyrimidine joined #moarvm
20:53 timotimo i'm glad you're working on unions again; i'd like to have them in SDL2 libraries for the SDLEvents
20:54 timotimo hm, alternatively having super efficient nativecast would be cool
20:55 timotimo native casting could work by just switching the STable of an object, right?
20:55 timotimo well, plus checking if the REPR actually allows doing that at all
20:55 jnthn Surely not switcing the STable.
20:56 kjs_ joined #moarvm
20:56 jnthn I thought you got back a new "wrapper" object pointing to the same underlying memory...
20:57 timotimo ah, right, it's a clone-ish operation
20:57 timotimo not a mutate-ish
20:57 timotimo i meant the type rather than the STable :)
20:57 jnthn ah, ok
21:05 danaj joined #moarvm
21:06 FROGGS joined #moarvm
21:19 jnthn Man are deopt bugs a pain to find...
21:22 timotimo i can only imagine
21:24 jnthn I don't think the problem is in the deopt code per se.
21:25 jnthn I'm re-organizing things
21:25 jnthn And having us re-calcuate the dominance before doing the second stage
21:26 jnthn And something the second stage does apparently, when run on inlined blocks, knackers deopt.
21:27 dalek MoarVM/spesh-value-prop: a114f5b | jnthn++ | src/spesh/deopt.c:
21:27 dalek MoarVM/spesh-value-prop: Further improvements to deopt debug output.
21:27 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/a114f5bfec
21:28 timotimo yeah i saw the earlier commits
21:32 FROGGS nwc10: can you please printf obj->vegval.l in t/04-nativecall/13-union.c:40 ?
21:32 FROGGS I wonder if it will be 1073758272
21:32 lizmat jnthn: testing for my @arr := array[int].new;, would it make sense to repeat these for int8, int16, int32, int64 ?
21:37 jnthn lizmat: Yeah, and num32 and num64
21:37 lizmat and uint8  etc. I assume ?
21:39 jnthn *nod*
21:39 jnthn Though not sure we need every single test on all of them
21:40 jnthn Just some sanity tests making sure you can create them, use them, etc.
21:43 lizmat and assume the rest is ok?  ok
21:44 lizmat is there a reason you're using lives_ok in e.g. lives_ok { @arr[1, 2] = 69, 70 }  ??
21:45 lizmat why not just do it ?  if it doesn't work, there is not much point in testing the rest, is there ?
21:47 jnthn Just to get the "what we were trying to do" in the test output
21:47 jnthn You don't need to replicate that for the later, sized tests
21:47 jnthn Those could also go in their own file
21:47 jnthn native-sized.t or so
22:07 flussence joined #moarvm
22:11 * jnthn found an off-by-one, it seems
22:13 jnthn But also I don't think we can go re-writing the return addresses of invoke instructions to outside of the inline region
22:13 jnthn 'cus it busts uninlining
22:14 jnthn uh, return registers I mean
22:15 timotimo not sure what that means ...?
22:15 timotimo changing what register an inlined block writes its result to?
22:17 jnthn When we inline we replace the return with a set
22:17 timotimo right
22:17 timotimo and that one shouldn't be touched, eh?
22:17 jnthn So normally if the last thing we do is an invoke
22:17 jnthn It looks like
22:18 jnthn sp_fastinvoke_o r36(3), r36(2), liti16(0)
22:18 jnthn set r18(7), r36(3)
22:18 jnthn goto BB(42)
22:18 jnthn Or so
22:18 jnthn But second_pass is turning that into
22:18 jnthn sp_fastinvoke_o r18(7), r36(2), liti16(0)
22:18 jnthn goto BB(42)
22:19 timotimo hooray, that one optimization i made works! :P
22:19 jnthn Well, in general, yes
22:19 jnthn Except unfortunately here it causes a problem
22:19 FROGGS hehe
22:20 jnthn Because the return value for the invoke is now pointed at a register outside of the inlinee
22:20 timotimo it doesn't know, though, right?
22:20 timotimo i mean
22:20 timotimo how could it
22:20 jnthn Meaning that if we uninline...boom.
22:20 jnthn Yeah, I don't know that your opt should have to know
22:20 jnthn I'm wondering if doing the same usage trick will cut it
22:21 timotimo could, yeah
22:21 jnthn That is, if the writer has a usage of 2, we should be fine.
22:22 timotimo i think it checks if the set only has the one user
22:22 jnthn Yeah
22:24 danaj joined #moarvm
22:29 jnthn It seems to help
22:29 jnthn Doesn't explode, and spesh log shows the set is not killed off there
22:34 jnthn That gets NQP fixed up
22:34 jnthn Alas, something doesn't go too well when compiling CORE.setting
22:37 dalek MoarVM/spesh-value-prop: 2123fcb | jnthn++ | src/spesh/inline.c:
22:37 dalek MoarVM/spesh-value-prop: Bump usage count of invoke-y ops inside of inline.
22:37 dalek MoarVM/spesh-value-prop:
22:37 dalek MoarVM/spesh-value-prop: This is because we must leave them writing to the same register to
22:37 dalek MoarVM/spesh-value-prop: allow for global deoptimization to work out. (Technically, another
22:37 dalek MoarVM/spesh-value-prop: register in the register scope of the inlinee is OK, but we should
22:37 dalek MoarVM/spesh-value-prop: already have dealt with that during spesh of the inlinee itself.)
22:37 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/2123fcbae3
22:39 dalek MoarVM/spesh-value-prop: 9936d44 | jnthn++ | src/spesh/deopt.c:
22:39 dalek MoarVM/spesh-value-prop: Fix off-by-one in locating inline region.
22:39 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/9936d4493c
22:39 dalek MoarVM/spesh-value-prop: d2b9aa5 | jnthn++ | src/spesh/deopt.c:
22:39 dalek MoarVM/spesh-value-prop: Further global deopt debug output tweaks.
22:39 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/d2b9aa50ed
22:47 timotimo aaw
22:47 timotimo but i'm glad this stuff is getting a little clean-up :)
22:49 jnthn Well, it's a little more than cleanup; it's enabling us to do optimization that dives into our inlinees too
22:49 timotimo ah
22:49 timotimo that's very good
22:50 timotimo are we actually relying on the SSA frontiers (or what they are called?) with any of our optimizations? as in: directly
22:50 jnthn Dominance frontiers?
22:50 jnthn We use those to get ourselves into SSA form.
22:50 jnthn They tell where the PHIs go.
22:51 timotimo those
22:51 timotimo OK
22:51 jnthn We use the dominance tree as a walking order
22:51 timotimo that part i know
22:52 timotimo i'm just wondering how we can make more use out of the stuff we already calculate all over the place
22:52 timotimo we also don't have a "merge facts" at PHIs opt, right?
22:52 jnthn No, not yet
22:52 jnthn There's quite a lot we don't do yet :)
22:52 timotimo we can likely merge "is concrete" flags often-ish at PHI borders
22:53 timotimo i think i'll put a tiny debug output probe in there and maybe implement a merge opt if it shows up some nice potential
22:54 jnthn Sure
22:54 flussence joined #moarvm
22:57 dalek MoarVM/spesh-value-prop: 95f7380 | jnthn++ | src/spesh/manipulate.c:
22:57 dalek MoarVM/spesh-value-prop: Move inline deopt annotations on delete also.
22:57 dalek MoarVM/spesh-value-prop:
22:57 dalek MoarVM/spesh-value-prop: We hadn't used to ever visit the inlined code during optimization, but
22:57 dalek MoarVM/spesh-value-prop: now our second pass is going to do so.
22:57 dalek MoarVM/spesh-value-prop: review: https://github.com/MoarVM/MoarVM/commit/95f7380625
23:02 [Coke] are .moarvm files machine specific?
23:03 jnthn No
23:03 jnthn You should be able ot take a moarvm file built on a 32-bit BE machine and run it on a 64-bit LE machine if you want.
23:04 [Coke] excellent, thanks.
23:12 jnthn 'night, #moarvm
23:13 timotimo 96% of phi nodes inspected during a simple example perl6 program have no intersecting flags
23:14 timotimo https://gist.github.com/timo/5b51f7c78c37d1fca7bd - all in all we get this
23:16 timotimo i'll put in the merging code and see what happens :)
23:20 timotimo well, of course it would segfault
23:26 xiaomiao joined #moarvm
23:51 timotimo there's apparently a safe subset of facts that i'm allowed to merge
23:52 timotimo not sure what to take home from that experience
23:54 timotimo spec tests look good so far
23:55 timotimo right now i'm only merging KNOWN_TYPE (unless divergent), DECONTED and KNOWN_DECONT_TYPE
23:56 timotimo having CONCRETE in there makes it blow up in the smart_coerce optimization by null pointer dereference (well, with an offset)

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