01:50 FROGGS_ joined 03:56 btyler joined 07:40 ingy joined 08:20 FROGGS[mobile] joined 08:53 brrt joined
brrt \o #moarvm 09:09
jnthn o/ brrt, #moarvm 09:42
brrt how's today
jnthn fine so far 09:43
not raining, have coffee... :)
How about for you? 09:44
brrt hot, hot, hot 09:47
but as it stands rain should come in about 6 hours 09:48
masak \o/
brrt hmm... 09:49
i think i can do sp_fastinvoke, that should be doable
but i'm off for lunch now :-) bbiab 09:50
jnthn k :) 09:52
dalek arVM: a4cdc2d | jnthn++ | src/spesh/inline.c:
Fix merging of inline table entries.

Need to add offsets to return address deopt location, locals, and lexicals.		 10:43
arVM: b0df62c | jnthn++ | src/spesh/deopt.c:
Improve deopt debug fprintfs.
10:55 brrt joined
brrt predicts that b0df62c1 will cause merge annoyance later on 10:57
jnthn Sorry
brrt np :-)
jnthn At least it's only commented out code ;)
That fixes the nasty deopt bug typevaropt was blocking on, though, it seems. 10:58
tadzik attempts cross-compiling nqp for ARM again
it's slooooow
brrt it's no problem, of course - i change the segments without merging them back, shouldn't be surprised if stuff breaks in the meantime
tadzik but probably still faster than doing it on device :)
brrt oh? good time for me to merge-update?
jnthn Maybe... 10:59
jnthn is just doing a spectest.
yeah, that cleans up the issues 11:01
So, probably a good time. 11:02
brrt ok, i'll update then
:-)
jnthn Warning: you'll be dragging in OSR too :) 11:04
brrt i think i've done that already 11:06
and it doesn't seem to have caused any troubles, probably because i haven't been able to JIT OSR-frames yet :-)
jnthn ah, ok :) 11:09
dalek MoarVM/moar-jit: 6b458f7 | (Tobias Leich)++ | src/6model/reprs/CPointer.c: 11:11
MoarVM/moar-jit: allow pointer math using CPointer repr
MoarVM/moar-jit:
MoarVM/moar-jit: This means that NativeCall's OpaquePointer type can be gistified as
MoarVM/moar-jit: OpaquePointer<0x7f9e8db8fda0>, which will be helpful for debugging
brrt facepalm
11:12 dalek joined
brrt i thought dalek recognised merges? 11:12
jnthn Only if you merge enough commits.
It goes on a "how many" heuristic, rather than looking at the topology 11:13
jnthn thinks of the world cup logo every time he hears "facepalm" :) 11:14
brrt lol
i don't have good hopes for belgium tonight 11:15
jnthn Playing a South American team in South America is quite a big ask... 11:17
brrt netherlands will be up against costa rica, and i'm actually expecting they'll win 11:19
jnthn Yes, I'd hope so.
brrt i'm neutral towards it, but i expect it :-) 11:20
jnthn Well, we know at least one European team is into the semis, but one or two more would be nice :) 11:21
brrt then if one of {netherlands, belgium} wins tonight, it'll be nicely balanced 11:22
jnthn aye 11:23
If both win, it'll be an entertaining semi :) 11:24
brrt indeed 11:25
jnthn Bring teams from all over the world, and the semi-final ends up being two that are right next to each other :)
brrt that's what i'm kind of hoping for
jnthn Even funnier if Germany manage to beat Brazil and final is something like Netherlands vs Germany, or Belgium vs Germany. But beating Brazil on home turf will take quite something... 11:26
brrt i'd be very surprised if that happened 11:27
can you remind me to blog today? 11:29
jnthn brrt: Blog today.
Though I guess you meant, later on today :)
brrt :-) and i'd also like your input on the following problem i'm having, or challenge, or call it what you will
later on perhaps
:-) 11:30
jnthn k
brrt basically, i have a number of 'system variables' - like the current frame, the compilation unit, the input args buffer, the out args buffer, etc
and i'd like to keep these in the callee-save registers, but i don't quite have enough of those do keep all of them, and moreover, it's wasteful to do so 11:31
what i do now is keep some of them at all times - threadcontext, compunit, work registers, inargs registers 11:32
and get all others on a temporary basis
but what i'd like to do is to have 'sections' of the jit graph where one set of system variables would be in certain frames, and at other times, other segments 11:33
i.e. i don't typically need to keep inargs in a special register for very long because - most of the time - all argument reading happens in the first basic block or so 11:34
jnthn Right.
Though there's no easy way to know where args reading ends 11:36
And calls could happen in the middle of it. 11:37
(sub foo($x = blah(), :$y) { }; foo(y => 'bear'))
brrt basically my idea was to have ops that require, e.g. the current frame, to 'ask' the jit graph to load the current frame, and have the compiler only emit loads at 'borders' 11:38
hmm i see
that's ok, still
that's why we have callee-save registes, after all :-)
jnthn true :) 11:40
brrt hmm... if that were the only 'codegen optimisation' i'd get done this summer, i'd still be (somewhat) happy, but not as happy as i could be 11:42
jnthn Well, I still see it as somewhat secondary to being able to JIT e.g. calls. :) 11:43
brrt agreed 11:44
but i'm getting to that right now :-)
jnthn True :-) 11:45
It'll be rather nice when some of the benchmarks from perl6-bench can benefit :)
brrt i don't suppose we have the code target of sp_fastinvoke at spesh time, or do we? 11:47
jnthn The point of sp_faskinvoke is it knows exactly where it's going 11:48
brrt hmm
jnthn "we know enough to inline it, but it doesn't make sense or contains things that make inlining impossible"
So we know the code target *and* the spesh candidate
brrt hmmm 11:49
jnthn (Meaning you may also statically know it's jitted :)) 11:50
brrt yes, i suppose so; but this doesn't seem to directly repesented in the spesh graph 11:52
jnthn The info is there, 'cus that's how the optimizer knows it can use sp_fastinvoke 11:56
brrt looks at it 11:57
jnthn It should just be that the register holding the invokee has a facts table entry with the code as the object value.
iirc there's a get facts function that takes a MVMSpeshOperand 11:58
brrt oh, that is actually quite likely; that'd be a good reason for sp_getspeshslot 11:59
jnthn Yeah, or you can just grab the spesh slot index. :) 12:00
and look it up that way
tmtowtdi :)
brrt :-) fortunately 12:01
jnthn Time to go shopping. bbiab. 12:16
brrt needs to be done, too 12:24
12:33 FROGGS_ joined
brrt seems to need greater amounts of caffeine today 12:34
[Coke] grrzzzcoffeee 12:47
brrt i only have tea right now, that might be the cause of it 12:48
bbiab 13:08
13:08 brrt left 13:39 carlin joined 14:34 brrt joined
brrt \o #moarvm 14:45
timotimo o/ 14:46
jnthn wb, brrt 14:50
timotimo wbrrt
brrt lol 14:51
14:55 tgt joined
dalek arVM: 84abb89 | jnthn++ | src/spesh/ (4 files):
Rename to ensure it's clear guards relate to args.

This will contrast them with log-based guards.		 14:58
brrt hmmm 15:05
it occurs to me that storing the 'jit return address' in the current frame is only possible when that frame is still... current 15:06
jnthn "current"? 15:08
brrt i.e. when i call MVM_frame_invoke and that updates the whole threadcontext, and cur_frame is changed to point to the callee frame, it is basically too late - or at least inelegant - to set the return address then
it will cause ugly bugs, is what i'm saying, i guess :-) 15:09
(because: what happens with tails calls?)
timotimo do we do tail call optimization in the jit? :)
jnthn MoarVM's execution strategy is an entire tail call optimization if you squint... :) 15:10
We don't recurse on the C stack.
brrt: Well, the invoke instructions stash the return address *before* calling MVM_frame_invoke.
brrt that is only true in a very limited sense :-) we do recurse on the MVMFrame stack 15:11
timotimo haha, right
jnthn Oh, sure. But not the C stack. Which is really important for not introducing continuation barriers.
timotimo but we do have frames that get allocated on a stack-like structure
jnthn Yeah. More a DAG than a stack, but yes :)
timotimo i generally know TCO as "not even allocate a new frame when recurring"
jnthn Well, Idid say you have to squint :P 15:12
timotimo and look the other way as well? :)
brrt wonders about the DAG-like nature of the frame graph
dalek arVM: ab8eb2d | jnthn++ | src/ (5 files):
Keep a table of added log-based guards.

Not updated with usages or used for anything yet; just initialized.
jnthn brrt: Well, there's two relationships: caller and outer.
timotimo ah, removal of unnecessary log guards
very good
jnthn timotimo: Well, that's what I'm preparing for, yes. 15:13
timotimo yup
i seem to recall you said deopt is kinda cheap?
i mean the jump itself
not running the spesh'd bytecode any more, even though we could, would probably be the bigger deal 15:14
brrt anyway.... my point is, i'd want to set the return address /before/ calling mvm_frame_invoke too, but that means the strategy of returning a label number to the 'driver' to set the continuation becomes an inelegant strategy, that also relies on the jit-frame also being the caller frame, and that might not hold if - for example - we could decide we didn't need the jit frame after the call anymore (i.e. TCO) 15:15
jnthn It's kinda cheap, but doing it when you're in an inlined thing has to go allocating frames and reconstructing the outer chain...
brrt outer is based on staticframe's in some way, right? 15:16
jnthn uh, caller chain...
No, outer is from statically knowing the code object.
timotimo of course
jnthn Which by definition you do if you've inlined stuff.
timotimo do you have a clue how often we deopt inlined things vs just speshed things in general?
jnthn Didn't do any measruements, but I know it can happen quite a lot. 15:17
And typically in places it needn't.
timotimo OK
brrt ok, i'm almost ready with my blog post, but at any rate, the gist of it is that i decided to do the following 15:26
a): mvm_jit_enter returns an integer which is nonzero if the frame has 'run its course', i.e. is at it's natural end, in which case b): the driver should call mvm_frame_try_return, because it'll have to know if it should exit the loop, and this way each of the code seems to have its own responsiblity 15:29
c): the jitted code will have to set its return address /before/ calling MVM_frame_invoke, and d): possibly just return 1 when done, zero when not 'done' (which can be directly returned to the interpreter 15:30
but, bbiab :-)
jnthn :) 15:31
15:45 zakharyas joined
timotimo i was a bit worried when i read the return value would either be a pointer to jump to or a negative value; aren't pointers unsigned? 15:45
dalek arVM: 80ab0b4 | jnthn++ | src/spesh/facts.c:
Copy log guard when computing dependent facts.
 15:50
arVM: 8131c29 | jnthn++ | src/spesh/optimize.c:
Add simple guard use analysis

Not perfect, but an over-approximation, to start with: if we ever ask for the fact, then consider it used.		 15:53
arVM: 708dd7d | jnthn++ | src/spesh/optimize.c:
Remember to copy log_guard with facts.
 16:02
arVM: 9357879 | jnthn++ | src/spesh/optimize.c:
Eliminate unused guards.
16:21 vendethiel joined 16:29 btyler joined
FROGGS_ jnthn: &foo:(Int,Num) is about selecting an already existing MMD candidate 16:40
we'd need something nice to declare a callable attribute of a CStructish class, and, be able to cast a pointer to something callable 16:41
jnthn std: class A { has &.x:(Int, Str --> Num); } # curious 16:46
camelia std 0f2049c: OUTPUT«ok 00:01 131m␤»
japhb_ o/ # Back from offline vacation :-) 16:51
jnthn Hope it was a nice vacation :)
japhb_ It was indeed.
Started looking at Rat/FatRat benchmarks for you, jnthn. I'm noticing that perl5's Math::BigRat is S-L-O-W. Like seriously-that-can't-be-right slow, in the case of my Harmonic Series test. 16:53
jnthn Wow
So slow that we beat it? :)
japhb_ Easily, when I was futzing at the command line. I haven't run 'em through perl6-bench yet, though; I was just refining the scriptlets I was going to use. 16:54
jnthn *nod*
FROGGS_ std: class A { has &.x:(Int, Str) returns Num; } 17:01
camelia std 0f2049c: OUTPUT«ok 00:01 130m␤»
FROGGS_ std: class A { has &.x:(Int, Str) returns Num is native('foo'); } 17:02
camelia std 0f2049c: OUTPUT«ok 00:01 133m␤»
FROGGS_ I'm not sure it is meant to be doing what we want though 17:03
18:31 zakharyas joined
dalek arVM/nativecast: 2b68449 | (Tobias Leich)++ | src/core/nativecall.c:
fix bogus declaration (copy&pasto)
 19:34
19:47 carlin joined 19:49 carlin joined 19:58 brrt joined 19:59 vendethiel joined 20:10 vendethiel joined 22:12 carlin joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!