01:33 diakopte1 joined 01:40 FROGGS_ joined
dalek arVM: 1d89654 | (Geoffrey Broadwell)++ | src/spesh/optimize.c:
Fix 'elimiante' typo in several places
 01:48
03:28 dalek joined 03:36 dalek joined 04:16 masak joined 06:19 brrt joined
brrt \o moar 06:19
nwc10 probably not relevant, and I've only read the Abstract, but cool :-) www.cs.princeton.edu/~appel/papers/memerr.pdf 06:49
"Using Memory Errors to Attack a Virtual Machine"
06:59 brrt joined
brrt paper-size, we can do that 07:01
(dissapointing match, yesterday, btw) 07:11
07:12 teodozjan joined
moritz only saw the first half, and wasn't really overwhelmed 07:21
brrt there was no reason to be overwhelmed indeed 07:23
nwc10 jnthn: Rakudo sanity tests pass for me with origin/set-removal but spectests fail. But ASAN is happy 07:31
it's fail fails, not ASAN barfs
sergot o/ 07:57
brrt \o 07:58
08:12 brrt left
nwc10 jnthn: we have normality, etc. valgrind and ASAN suggest it's "your problem" (ie not undefined behaviour. Hence a logic bug) 08:36
08:36 teodozjan joined 09:12 rurban joined
jnthn nwc10: Weird sanity passes... 09:40
nwc10 yes, but then again weird that that other stuff diverged yesterday
jnthn yes.
nwc10 fire up a Linux VM and see if you can locally replicate sanity? 09:41
jnthn yeah
But after gorging on Perl 6 hacking all day yesterday I should do a few $dayjob things today before that :)
09:44 brrt joined
nwc10 like "eat lunch"? :-) 09:45
brrt ok, i have a script that counts opcodes that JIT currently bails on 09:46
slight issue - it is a bit self-referential, because written in perl6 09:47
jnthn haha 09:48
nwc10 dogfood++
timotimo i didn't have a big problem with that when i built spesh-diff, but i had to turn on spesh dumping with an env var anyway ...
brrt takedispatcher seems to be an extop? 09:50
jnthn no
core
And easy. 09:51
brrt ok, i like them that way
jnthn Read a value from a field in tc, put it in a register, NULL the tc field.
dalek arVM/moar-jit: e2e9564 | (Bart Wiegmans)++ | / (4 files):
Add script to measure opcodes the JIT bails on

Because it is written in perl6, it mostly measures the ops that are used by the script itself, as well as possibly the rakudo compiler.		 09:58
brrt oh, that really seems easy :-)
10:04 ggoebel111118 joined 10:11 nebuchadnezzar joined
dalek arVM/moar-jit: 539b1f5 | (Bart Wiegmans)++ | src/jit/ (4 files):
Add takedispatcher / setdispatcher

These were very common bail points.		 10:21
arVM/moar-jit: ab1b19b | (Bart Wiegmans)++ | src/jit/ (4 files):
Add getcode op
brrt btw, it doesn't always work very well, reading the jit log as we're going along
jnthn Could you not read another JIT log in? :) 10:22
brrt maybe open the jit log appending
possibly
timotimo brrt: can has an example output? :3 10:26
brrt sure
gist.github.com/bdw/4b0836d1fe0ce557bfeb is what it ought to look like 10:28
timotimo these top ops don't seem that hard 10:30
also, isnull, unless_o, not_i ... :)
jnthn sp_fastcreate should at lesat be easy.
yeah, isnull and not_i too
if_o and unless_o are more involved... 10:31
timotimo oh, right
jnthn For the same reason decont is
timotimo boolification specs
jnthn All of these might invoke.
timotimo we wanted to spesh those into different sp_ ops based on how they boolify
jnthn Well, not even sp_ ops
timotimo but it'll require allocating new register names out of thin air
jnthn Often there's already ops
timotimo oh 10:32
jnthn Like isconcrete :)
Now our frames can grow in size during spesh, allocating new registers is less of a problem.
Just didn't implement it yet. 10:33
timotimo ah, SMOP then.
brrt for some reason i only get a very small list 10:36
with my last update
timotimo jnthn: is there anything to be won from making frames shrink during spesh? 10:40
or is that kind of exactly what jit will end up doing?
brrt frames shrink? 10:41
brrt no comprehend 10:42
timotimo IIRC, each register is an offset to the "stack" 10:43
so the highest register in use inside a frame tells us how big the chunk of memory is that'll get used for executing that frame 10:44
now if we eliminate a bunch of registers in the middle during spesh, the frame might stay the same size, but have lots of unused slots in the middle
brrt i don't think you're elimininating registers just yet 10:45
eliminating
10:45 cognominal joined
brrt but i may be wrong 10:46
jnthn Well, we might in some cases delete instructions such that some registers go unused
brrt and anyway, the jit will be plenty happy wit just working with the registers spesh delivers, so there won't be a jit-specific register elimination (at least not yet)
jnthn If the thing contains deopt points, though, then we can't just go shrinking the frame easily...
timotimo ah 10:51
most interesting things likely will contain deopt points :S
jnthn Right.
brrt y dis no work 10:55
jnthn ur doin it rong
brrt but what?
jnthn does the code take a penalty anywhere? :P 10:56
nwc10 valgrind?
jnthn wonders what exactly isn't working :)
brrt the perl6 count-jit-bail-ops tool isn't working as it should, i.e. it only shows a small set of ops 10:57
timotimo hm. 10:58
print "MATCHED" and "NOMATCH" in front of all $line s?
brrt goot point 10:59
timotimo to check if the regex is correct and the input looks the way it ought to?
also, make extra sure you're not reading the file the vm is writing at that moment
:P
brrt that is actually precisely what is happening, however that doesn't actually seem to be a problem 11:00
my regex is just wrong 11:02
but, my regex isn't wrong 11:04
:-(
11:33 jnap joined
[Coke] ... I thought e2e9564 said "the JIT balls". *sigh* 12:57
jnthn haha 12:59
13:14 teodozjan joined 13:25 brrt joined 13:27 zakharyas joined 13:34 JimmyZ joined
dalek arVM/moar-jit: 790b02f | (Bart Wiegmans)++ | tools/count-jit-bail-ops.p6:
Have jit bail ops counter take arguments
 13:39
jnthn No, not "jit ball ops"... :P 13:40
13:50 btyler joined 14:10 carlin joined 15:10 brrt joined 15:17 FROGGS joined
FROGGS m: say "Ā»m\c[COMBINING DIAERESIS]Ā«" 15:29
camelia rakudo-moar 4cad54: OUTPUTĀ«Ā»mĢˆĀ«ā¤Ā»
16:07 btyler_ joined 16:42 brrt joined
dalek arVM/moar-jit: e6e73cb | (Bart Wiegmans)++ | src/jit/ (4 files):
Add support for sp_fastcreate
 16:52
jnthn ...and is_null sneaked in there too 16:57
*isnull
dalek arVM/moar-jit: 6c305d3 | (Bart Wiegmans)++ | / (2 files):
Ignore bytecode dump files in git
 17:01
brrt yes, is null did, but that is supposed to be another commit? 17:10
oh, no, wasn't
oops! 17:16
decont is big, by the way
as in, occurs often
jnthn Yes :) 17:23
spesh kills many but not all of them.
It can also invoke.
(in special cases) 17:24
jnthn suggests working out a plan for the invoke-maybe ops like decont, smart stringify, smart numify, etc.
And solve the problem the same way for all of them.
I think they are all void functions. 17:25
So we can actually return a "did it invoke" indicator.
17:31 zakharyas joined
dalek arVM/moar-jit: e7982c9 | (Bart Wiegmans)++ | src/jit/ (4 files):
Add decont

This doesn't actually compile yet.		 17:32
brrt oh.... decont can invoke
yes, good point 17:33
hmm
undo my last commit then
jnthn I'd say there are, aside from Just Implementing Ops, 3 bigger pieces left to consider
1) Ops that might invoke
2) OSR 17:34
3) extops
dalek arVM/moar-jit: 83d5cc4 | (Bart Wiegmans)++ | src/jit/graph.c:
Remove decont again as it might invoke
brrt extops are - afaik - function calls, right?
jnthn Right
brrt ok, then they ought to be simple
jnthn Though some might not play well with not being in the interpreter.
But we can mark those out.
brrt hmmm
the ops that might invoke bit is a biggy 17:35
jnthn Yes
brrt i'm not sure about the complexity of OSR
jnthn It's not too bad.
brrt i suppose that if you know (in spesh term) in what basic block you're starting, it should be doable
jnthn Yes, there's an annotation
brrt oh? good 17:36
jnthn MVM_SPESH_ANN_DEOPT_OSR
I don't expect getting the OSR thing to work with the JIT to be more than a days work for you :)
brrt hopes not
jnthn But yeah, the may-invoke ops is where I'd look next. 17:37
brrt safe bet is - always return to the interpreter just in case
or, compare cur_op pointer with the jit bytecode 17:38
jnthn They're common enough that'll suck performance wise...plus the PC will be in the wrong place...
brrt why is that?
jnthn Well, I'd use the fact they're all void to actually make them return a "did it invoke"
brrt are may-invoke ops also at the end of a bb?
(probably not)
jnthn No
99.9% of decont ops do not invoke.
brrt how about an inner interpreter runloop? :-p
jnthn No, that's evil
brrt you have no idea about evil 17:39
you know what'd be evil?
jumping to the labels provided by cgoto
jnthn Just have the function indicate if it invoked, check the return value, and if it did fall out of the JIT...
:P
That's awesome :P
Though only on compilers that support it :)
brrt true
jnthn Also, we'd be in the wrong frame? :) 17:40
brrt yeah
jnthn As in, C stack frame
brrt wonders if that can't be hacked either
jnthn I don't see why not :) But it feels like a scary optimization :)
brrt pretty scary
jnthn For now I'd keep it simple. 17:41
brrt but yes, indicate if it invoked seems good
note that this follows from '*tc->interp_cur_op == tc->cur_frame->spesh_cand->jitcode->bytecode'
jnthn Yeah. I dunno if you can use the current C function call jit graph node but make a return type that is something like DidItInvoke and then emit the check-and-fall-out if that's the return type. 17:42
brrt i could add that, yes
jnthn Well, just thinking if you do it that way you can handle the various invoke-ishes in a common way :)
brrt nods 17:43
jnthn Anyway, I'd put those fairly high on the todo list.
If next week we land OSR and extops things start looking rather exciting. :) 17:44
brrt yes. they're common enough, too
timotimo++ also gave me the great advice 'please document how you do stuff', so i think i'll get to that too
jnthn As in, we'll be able to have perl6-bench things with native ints JIT-compiled :) 17:45
Yes, that's also a good idea :)
brrt ok, i'll put it on my list 17:47
the jit-jit call is also something i'd still like to get at 17:48
[Coke] is any of the jit stuff back in trunk yet? huh ?huh? huH? huH? ;) 17:52
jnthn [Coke]: No, but moar-jit is being kept sync'd up with trunk quite often :) 17:53
So there's not some epic merge to come.
brrt fortunately
[Coke] brrt++ brrt++ brrt++ brrt++ 17:54
brrt :-) 17:55
i'm going to do some bicycle fixing now :-) see you tomoorow probably 17:56
17:57 brrt left
jnthn o/ 17:58
17:59 FROGGS[mobile] joined 18:05 ingy joined 18:56 teodozjan joined 19:05 zakharyas joined 19:57 zakharyas joined 21:34 FROGGS joined
dalek arVM/moar-jit: c44ab71 | jnthn++ | src/jit/graph.c:
Put declaration first, to fix MSVC build.
 22:20
arVM/moar-jit: 062641d | jnthn++ | src/jit/graph.c:
Fix a == that shoulda been =.

Was found by an MSVC warning.		 22:23
22:33 masak joined, moritz joined, daxim joined 22:34 jnap joined 22:36 flussence joined, japhb joined, camelia joined, cxreg joined, harrow joined, tokuhirom joined, timotimo joined, ashleydev joined 22:38 BinGOs joined
dalek arVM/moar-jit: 59d4385 | jnthn++ | src/jit/emit_ (3 files):
Move declarations above code, to keep MSVC happy.

With this and other patches, moar-jit is back to building on MSVC.		 22:43
jnthn brrt: CORE.setting JIT bail reasons, fwiw: gist.github.com/jnthn/45b302ebda86a25769ef 23:01
(yes, this means the JIT runs well enough on Windows to build CORE.setting...also good to know :)) 23:02
'night 23:05

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!