01:02 xiaomiao joined 02:48 ilbot3 joined 04:02 FROGGS_ joined 08:41 rurban joined 08:58 kjs_ joined 09:42 zakharyas joined 11:37 kjs_ joined
FROGGS_ okay, developing for mobile phones is a little bit unfun 11:43
I can compile all deps for QNX except libuv (yet) 11:44
but even if I could compile moarvm and nqp... I have no shell where I could test a one-liner
jnthn o.O
Yeah, sounds a bit unfun 11:45
FROGGS_ there are sample C apps where I would render text using OpenGL...
but all in all sounds like too much work 11:47
jnthn yeah 11:48
FROGGS_ it might be more worthwhile to look at android
though I guess one cant do much with C there
jnthn Especially when we don't have an OpenGL module yet, afaik?
FROGGS_ true
11:50 kjs_ joined
jnthn ah, it seems we do tweak successors in the spesh graph on inlining 11:51
oh, heh. If we inline something but then determine the branch we inlined it into is dead, I guess we could hit this issue... 11:52
12:51 zakharyas joined
dalek arVM/spesh-value-prop: f99aab5 | jnthn++ | src/spesh/graph.c:
For now, re-compute preds before dominance.

Seems we might be getting our succ/pred out of sync in some of the optimizations. Work around it for the moment.		 12:55
arVM/spesh-value-prop: bf1716e | jnthn++ | src/spesh/optimize.c:
Rename second_pass to value_propagation.

It will gradually grow into a common pass for a number of related optimizations.
arVM/spesh-value-prop: d7444cf | jnthn++ | src/spesh/optimize.c:
Re-organize and document optimization top-level.

Re-order code to match stage order.
arVM/spesh-value-prop: 84ff588 | jnthn++ | src/spesh/optimize.c:
First attempt at dominator re-computation.

This also gets us using the graph.c version of BB elimination, and trying to fix things up. Alas, it breaks a few things.
13:26 dalek joined 13:28 zakharyas1 joined
nwc10 jnthn: yesterday, ASAN was happy with your new branch. Today, your new MoarVM branch SEGVs very early in the NQP build 16:27
I assume that you knew this already.
jnthn It doesn't even pass NQP's make test with a ready built NQP 16:28
I didn't try and NQP build without working that bit out.
btw, everything except the final commit should be fine 16:30
That one got pushed 'cus I was leaving home for a week and wanted it somewhere so I can continue working. 16:31
FROGGS_ i.imgur.com/kaaYOwW.png :/ 16:32
though, it is nice to have a bash, binutils, make, git and an almost working perl on my tab... 16:33
jnthn aww 16:36
FROGGS_ I could attempt to cross compile it, but it would be nice to Just Do It on that machine 16:37
timotimo is there no ssh server for android? :) 16:46
flussence depends which rom you're using; CM has a pretty decent command line setup 16:52
no gcc though, aww :( 16:53
FROGGS_ timotimo: there is 16:54
I've used this: kevinboone.net/kbox2.html 16:56
you dont have to root your device for this, which is nice
dalek arVM/spesh-value-prop: 660bcd8 | jnthn++ | src/spesh/deopt.c:
Fix deopt debugging aid; #define it out.

Makes it easier to turn it on/off as needed.		 17:14
nwc10 jnthn: yes, previous HEAD^ passes 17:16
jnthn nwc10: Ok, good to know 17:20
The last thing that happens before the test I have explodes is a missed JIT deopt idx 17:23
So something's rotten
17:30 kjs_ joined
jnthn detrain & 17:34
[Coke] that was a pleasant surprise; went to test install of moarvm on another os x box and got a prebuilt binary 17:48
17:50 diakopter left
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:52
[Coke] I can run a test on osx ā€¦ 17:53
timotimo that's what i was going to suggest if that was the major blocker 17:54
Invalid typename 'Poinder' in parameter declaration. Did you mean 'Pointer'? 18:06
[Coke] timotimo: what branch of which repo? 18:13
timotimo i don't know 18:18
18:21 kjs_ joined
timotimo Lexical with name '$x' has a different type in this frame 18:33
hm ... how?
dalek Heuristic branch merge: pushed 59 commits to MoarVM/union by FROGGS 18:38
FROGGS_ [Coke]: you'd need MoarVM/union + nqp + rakudo/union (HEAD of all of them) 18:48
timotimo: we also need the union support in the jvm backend before we can merge it
timotimo oh, damn 18:50
FROGGS_ should not be a big issue 18:53
dalek arVM: e39a7d7 | FROGGS++ | src/main.c:
use new MVM_vm_set_* functions
 19:16
nwc10 FROGGS_: you are making little endian assumptions in the union test in your branch: paste.scsys.co.uk/469453 19:38
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
FROGGS_ yeah
nwc10 also, I'm suprised that the "char in union" tests aren't failing too
dalek arVM/cpp2: 6345e59 | FROGGS++ | / (8 files):
reapply all commits for C++ support
 19:53
FROGGS_ the cpp branch seems unmergable... for some reason
now let's think about unions on BE 19:54
m: say (1 +< 30).fmt('%#b') 20:03
camelia rakudo-moar 1fdb76: OUTPUTĀ«0b1000000000000000000000000000000ā¤Ā»
FROGGS_ ahh, of course char works accidently
m: say 1 +< 30 +> 24 == 1 +< 6 # because 20:05
camelia rakudo-moar 1fdb76: OUTPUTĀ«Trueā¤Ā»
FROGGS_ so I did not choose my test cases carefully enough :o) 20:06
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:08
so the Perl 6 tests should probably just test if $union.i returns what we have written via C to the char "slot" 20:09
or we calculate an offset for members of a union that are smaller than the union itself? 20:17
nwc10 I'm not hugely awake, and I'm not sure either 20:21
FROGGS_ np, I am just thinking loudly :o) 20:24
20:37 pyrimidine joined
timotimo i'm glad you're working on unions again; i'd like to have them in SDL2 libraries for the SDLEvents 20:53
hm, alternatively having super efficient nativecast would be cool 20:54
native casting could work by just switching the STable of an object, right? 20:55
well, plus checking if the REPR actually allows doing that at all
jnthn Surely not switcing the STable.
20:56 kjs_ joined
jnthn I thought you got back a new "wrapper" object pointing to the same underlying memory... 20:56
timotimo ah, right, it's a clone-ish operation 20:57
not a mutate-ish
i meant the type rather than the STable :)
jnthn ah, ok
21:05 danaj joined 21:06 FROGGS joined
jnthn Man are deopt bugs a pain to find... 21:19
timotimo i can only imagine 21:22
jnthn I don't think the problem is in the deopt code per se. 21:24
I'm re-organizing things 21:25
And having us re-calcuate the dominance before doing the second stage
And something the second stage does apparently, when run on inlined blocks, knackers deopt. 21:26
dalek arVM/spesh-value-prop: a114f5b | jnthn++ | src/spesh/deopt.c:
Further improvements to deopt debug output.
 21:27
timotimo yeah i saw the earlier commits 21:28
FROGGS nwc10: can you please printf obj->vegval.l in t/04-nativecall/13-union.c:40 ? 21:32
I wonder if it will be 1073758272
lizmat jnthn: testing for my @arr := array[int].new;, would it make sense to repeat these for int8, int16, int32, int64 ?
jnthn lizmat: Yeah, and num32 and num64 21:37
lizmat and uint8 etc. I assume ?
jnthn *nod* 21:39
Though not sure we need every single test on all of them
Just some sanity tests making sure you can create them, use them, etc. 21:40
lizmat and assume the rest is ok? ok 21:43
is there a reason you're using lives_ok in e.g. lives_ok { @arr[1, 2] = 69, 70 } ?? 21:44
why not just do it ? if it doesn't work, there is not much point in testing the rest, is there ? 21:45
jnthn Just to get the "what we were trying to do" in the test output 21:47
You don't need to replicate that for the later, sized tests
Those could also go in their own file
native-sized.t or so
22:07 flussence joined
jnthn found an off-by-one, it seems 22:11
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
'cus it busts uninlining
uh, return registers I mean 22:14
timotimo not sure what that means ...? 22:15
changing what register an inlined block writes its result to?
jnthn When we inline we replace the return with a set 22:17
timotimo right
and that one shouldn't be touched, eh?
jnthn So normally if the last thing we do is an invoke
It looks like
sp_fastinvoke_o r36(3), r36(2), liti16(0) 22:18
set r18(7), r36(3)
goto BB(42)
Or so
But second_pass is turning that into
sp_fastinvoke_o r18(7), r36(2), liti16(0)
goto BB(42)
timotimo hooray, that one optimization i made works! :P 22:19
jnthn Well, in general, yes
Except unfortunately here it causes a problem
FROGGS hehe
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?
i mean
how could it
jnthn Meaning that if we uninline...boom.
Yeah, I don't know that your opt should have to know
I'm wondering if doing the same usage trick will cut it
timotimo could, yeah 22:21
jnthn That is, if the writer has a usage of 2, we should be fine.
timotimo i think it checks if the set only has the one user 22:22
jnthn Yeah
22:24 danaj joined
jnthn It seems to help 22:29
Doesn't explode, and spesh log shows the set is not killed off there
That gets NQP fixed up 22:34
Alas, something doesn't go too well when compiling CORE.setting
dalek arVM/spesh-value-prop: 2123fcb | jnthn++ | src/spesh/inline.c:
Bump usage count of invoke-y ops inside of inline.

This is because we must leave them writing to the same register to allow for global deoptimization to work out. (Technically, another register in the register scope of the inlinee is OK, but we should already have dealt with that during spesh of the inlinee itself.)		 22:37
arVM/spesh-value-prop: 9936d44 | jnthn++ | src/spesh/deopt.c:
Fix off-by-one in locating inline region.
 22:39
arVM/spesh-value-prop: d2b9aa5 | jnthn++ | src/spesh/deopt.c:
Further global deopt debug output tweaks.
timotimo aaw 22:47
but i'm glad this stuff is getting a little clean-up :)
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
that's very good
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?
We use those to get ourselves into SSA form.
They tell where the PHIs go.
timotimo those 22:51
OK
jnthn We use the dominance tree as a walking order
timotimo that part i know
i'm just wondering how we can make more use out of the stuff we already calculate all over the place 22:52
we also don't have a "merge facts" at PHIs opt, right?
jnthn No, not yet
There's quite a lot we don't do yet :)
timotimo we can likely merge "is concrete" flags often-ish at PHI borders
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:53
jnthn Sure 22:54
22:54 flussence joined
dalek arVM/spesh-value-prop: 95f7380 | jnthn++ | src/spesh/manipulate.c:
Move inline deopt annotations on delete also.

We hadn't used to ever visit the inlined code during optimization, but now our second pass is going to do so.		 22:57
[Coke] are .moarvm files machine specific? 23:02
jnthn No 23:03
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.
[Coke] excellent, thanks. 23:04
jnthn 'night, #moarvm 23:12
timotimo 96% of phi nodes inspected during a simple example perl6 program have no intersecting flags 23:13
gist.github.com/timo/5b51f7c78c37d1fca7bd - all in all we get this 23:14
i'll put in the merging code and see what happens :) 23:16
well, of course it would segfault 23:20
23:26 xiaomiao joined
timotimo there's apparently a safe subset of facts that i'm allowed to merge 23:51
not sure what to take home from that experience 23:52
spec tests look good so far 23:54
right now i'm only merging KNOWN_TYPE (unless divergent), DECONTED and KNOWN_DECONT_TYPE 23:55
having CONCRETE in there makes it blow up in the smart_coerce optimization by null pointer dereference (well, with an offset) 23:56

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!