01:28 vendethiel joined 01:49 ilbot3 joined 03:14 danaj joined 03:45 FROGGS_ joined
dalek arVM: c2c49cb | timotimo++ | src/jit/emit_x64.dasc:
emit add, sub, bor, band, bxor with constant if possible

we end up doing one of these two variants 157 times during a full rakudo compile; sadly it only saves a single mov instruction if the source and target registers are the same, but it removes stack access in any case.
i expect the next generation of our jit to do this kind of opt automatically for pretty much every operation, but that is not now.		 04:05
timotimo i had this nagging thought and it prevented me from falling asleep ... :P
next step could be to remove any const_i instruction that becomes useless due to this 04:06
timotimo has another patch handy that'll improve generated code size a bit more 04:43
we often do getspeshslot for different spesh slots into the same register twice in a row; my current patch kind of fixes the symptom, but ideally the code that emits the second getspeshslot ought to be smart enough to re-use the previous spesh slot (that would also reduce the size of spesh'd frames) 04:44
and since a getspeshslot is two movs, we can save 2 movs very, very often
bytes and bytes and bytes of instructions saved! 04:45
dalek arVM: d75a612 | timotimo++ | src/spesh/optimize.c:
kill duplicate getspeshslot ins for the same register

ideally, the piece of code that generates these would re-use the previous spesh slot, but that's for someone more awake to do.
turns 4 mov instructions into 2.		 04:50
timotimo m: all frames compiled during a full rakudo compilation now take only { 906436 / 915831 } as many bytes" 04:54
camelia rakudo-moar 55ed38: OUTPUT«===SORRY!=== Error while compiling /tmp/KyuOeAvQ4M␤Two terms in a row␤at /tmp/KyuOeAvQ4M:1␤------> led during a full rakudo compilation now⏏ take only { 906436 / 915831 } as many b␤ expecting any of:␤ infix␤ infi…»
timotimo m: say "all frames compiled during a full rakudo compilation now take only { 906436 / 915831 } as many bytes"
camelia rakudo-moar 55ed38: OUTPUT«all frames compiled during a full rakudo compilation now take only 0.9897416 as many bytes␤»
timotimo hm, only 1% saved?
m: say "all frames compiled during a full rakudo compilation now take only { 100 * 906436 / 915831 }% as many bytes" 04:55
camelia rakudo-moar 55ed38: OUTPUT«all frames compiled during a full rakudo compilation now take only 98.9741557% as many bytes␤»
07:30 brrt joined
brrt hold on timo :-) 07:30
that patch will only work when the constant is small (< 32 bits wide)
i'm not sure if it is true for all of x86-64, but if i recall correctly most opcodes can only take a 32 bit immediate value 07:31
(that said, it is a pretty nice fix :-))
now i'm looking for a good way to check if a number fits into 32 bit; and a further complexity is negative numbers 07:52
(pushed changes to dynasm, by the way) 08:03
09:14 vendethiel joined
nwc10 jnthn: I baked you a branch, called version-bump 09:28
at gitlab.com/nwc10/MoarVM.git (which I think you have as a remote "nwc10")
jnthn looks 09:31
1c86576486221 lies! 09:33
09:33 Peter__R joined
jnthn uh, well, it's confusing :) 09:33
09:33 TimToady_ joined
jnthn But either way, if we're bumping to 5, then this line: 09:33
MVMuint16 slvs = cu->body.bytecode_version >= 4 ? read_int16(pos, 40) : 0; 09:34
Need not stay
nwc10 oh bother. I missed one?
jnthn Two :)
nwc10 jnthn++ # review
I fail
I shall have another go, and get better at double checking grep 09:35
jnthn :) 09:36
dalek arVM: 2b14b67 | nicholas++ | src/6model/serialization.c:
Bump minimum serialization format version.

Now that we've rebootstrapped, we no longer need the code to read older serialization versions.
Again, mostly removal of if statements with ...->root.version checks, and re-indenting because of the blocks this eliminates.		 09:39
jnthn That one was fine, so it's in
nwc10 thanks 09:54
stupidity should now be fixed as a branch version-bump1 10:18
jnthn Thanks, looks better 10:20
nwc10 sorry about the previous cock up
jnthn np 10:23
That's what review is for
nwc10 agree. but I should have spotted them 10:25
dalek arVM: 9349f87 | nicholas++ | src/core/bytecode.c:
Formally bump minimum bytecode version to 5.

The code suggests that versions back to 2 are supported, but it has effectively been at 4 for a very long time, because there is conditional code relating to earlier versions. Additionally, the serialization blobs of earlier bytecode files would be rejected, because they will be using a serialization format version we now no longer support.		 10:29
timotimo brrt, that's not a problem, the only constants ever used were 1, 2, 3, 4 and 255 ;) 10:36
the dynasm changes don't seem that immense :S 10:42
jnthn They looked like a few patches from upstream 10:44
Grr, the remaining explosion in the concurrent-restarter thing is proving rather tricky to locate
timotimo the only change that looks like a bugfix or so is in the arm module, which we don't use yet 10:48
and in x86 and 64 we get support for some environment saving/restoring ops, looks like 10:49
i was quite surprised to see that one of the biggest frames we compile is actually ws 10:50
but ws in rakudo is quite involved, and it probably inlined some things?
i wonder if i should try to compact the sslots?
first i ought to put in some logging to see how many sslots are saved in how many frames 10:51
jnthn It probably inlined some things, yes 10:53
timotimo it's at about 10 kilobytes 10:54
jnthn Of JITted output? 10:55
timotimo i think i want to put in removal of the cheapest of BB "redirections" where we have BBs that consist of a single goto
yes
jnthn So JIT
timotimo very 10:58
does much stand in our way to move blocks from inlined spesh graphs much closer to where they were inlined to? 10:59
i expect a long jump would for sure kill many instruction cache lines 11:00
especially since we don't have any code (as far as i can tell) to align bbs (or much of anything)
jnthn It may not be overly bad. It's an unconditional branch, so it's predictable 11:03
Not a lot stands in our way. I know we can't do it for ones that deopt.
Uh, at least I think wecan't
*we can't
m: say 0x016e 11:08
camelia rakudo-moar 652c24: OUTPUT«366␤»
timotimo in ws we generate a jumplist instruction and then a bunch of BBs that are exclusively a single goto statement 11:09
19 of those in a row
those BBs, i mean
jnthn uh, wow...it seems the $vow.keep call is failing 'cus somehow keep ends up getting resolved to Null
timotimo we seem to be doing that for every jumplist
o_O
"cannot invoke this representation: null"? 11:10
jnthn Right
I would suspect method cache lazy deserialization except...it looks correct 11:15
(as in, already has appropriate concurrency control)
jnthn away for a bit 11:25
timotimo i wonder in what cases i have to bail out because of handlers and such 11:27
oh, we may not be able to move inlined BBs to the inlining block if they are inside a handler's scope, as they follow the linear order 11:31
11:37 Peter_R joined
timotimo in spesh's manipulate.c, the remove_successor function uses MVM_throw_exception_adhoc, which might want to be a panic instead? (because having that be catchable is kinda weird) 11:55
but we don't have a specific exitcode for spesh-related errors yet 11:56
vendethiel jnthn++ # blog 12:38
13:05 brrt joined
timotimo something i'm doing with shuffling preds and succs around makes the code end up in the interp loop with a tc of null 14:11
i can't seem to spot the mistake :\ 14:32
dalek arVM/union_goto_chains: 1023164 | timotimo++ | src/spesh/optimize.c:
try to turn chains of two gotos into a single one

currently dies when trying to find ourselves as a succ's pred after it worked a single time		 14:34
timotimo ^- maybe someone can spot the problem?
15:02 dalek joined 16:06 brrt joined 16:19 TimToady joined
dalek arVM: f23e56a | brrt++ | src/jit/emit_x64.dasc:
JIT - check if constant value fits in 32 bit

This checks if the constant value in an arithmetic operation actually fits in the 32 bits immediate value size limit of x86. Usually that will be true, but we'd better be safe than sorry.		 16:38
brrt so, that gives me a bit of peace :-) 16:39
i must say, timotimo++ for the creativity with which you find optimisation possiblities 16:40
brrt afk & 16:41
16:41 brrt left 17:18 zakharyas joined
timotimo i just look at spesh output and jit output and things become obvious ;) 17:27
18:05 zakharyas joined
FROGGS :o) 18:26
18:27 cygx joined
cygx oO( You get used to it, though. Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead. ) 18:27
timotimo: ^^ 18:28
FROGGS *g* 18:29
timotimo also, brrt, i find your compliment slightly exaggerated 18:34
TimToady he was being creative :) 18:55
timotimo hah 19:08
19:56 brrt joined
brrt \o (for a few minutes) 19:57
i don't think i'm exaggerating though :-) 19:58
anyway... i'm reading the luajit2 code...
i'm really glad we're using dynasm for code generation so far
also... i still think i'd want to add a new 'failure function' for moarvm internally 20:01
jnthn brrt: A panic with more info?
brrt so that we can let users know we screwed up, without throwing catchable exceptions
yes
jnthn Any reason not to adapt panic?
brrt well. i was told panic would happen only if we weren't sure our memory layout was still correct 20:02
jnthn Hm, point
brrt so in that case, you can't go ahead and try and make a backtrace
jnthn *nod*
brrt i'm talking about the cases wherein we MVM_exception_throw_adhoc()
maybe we should call it MVM_we_did_something_dumb() 20:03
MVM_oops() :-)
jnthn A lot of MVM_panics today aren't actually at "we're SO hosed!" points 20:05
dalek arVM: 0551316 | FROGGS++ | src/6model/serialization.c:
cope with null string in sc->body->description in ex
 20:06
brrt hmmm 20:07
jnthn I agree we should split the two, though.
One for extreme "we're out of or corrupted memory" situations that prints a message and gets out
And another for the rest of the time 20:08
brrt nods
jnthn Don't mind too much on naming
brrt no, neither do i; for some reason that doesn't make it much simpler :-P 20:09
hmm, it'd be really simple just to MVM_dump_bactrace() 20:12
assuming stderr is a reasonable place to dump it
jnthn Yeah
That means we need a tc
Which is fine if we're not in a memory-hosed situation 20:13
brrt right 20:14
i see a particularly sneaky error now; throwning a lexotic from the JIT might result in throwing an adhoc if no matching offset can be found 20:15
if you're expecting something thrown, there's a reasonable chance not to figure out that something unrelated was thrown
do we want to pass an error code? 20:18
jnthn Not sure an error code helps a great deal 20:21
A unique message is far more helpful
('cus we know where in the code we paniced) 20:22
brrt a lexotic is always a control exception, isn't it?
jnthn Yeah
brrt right, got it
do we want those (lexotics) - when they fail - to throw an exception, or to semi-panic? 20:23
right now these functions throw adhoc exceptions
TimToady you mean like the 9 places that can throw ");
oops
... Cannot look up attributes in a type object
jnthn TimToady: That's a regular, catchable, exception, not a panic. 20:24
We're talking about panics, where we get into an unrecoverable mess. 20:25
Of course, can factor the throwing of the "cannot look up attributes in a type object" one out into a single function that we call to throw it
brrt or, in my case, messes that are recoverable in theory, but very much a VM programmer error (rather than a perl6 programmer error)
jnthn brrt: True 20:26
Anyways, I'm off for the evening, to get some rest 20:27
o/ 20:28
brrt rest well :-) 20:30
20:35 cygx left
FROGGS that one is new: 20:36
src/jit/emit_x64.dasc:637:17: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘MVMint64’ [-Wformat=]
MVM_jit_log(tc, "accumulator for %s stayed in memory and constant value %d used\n", ins->info->name, value);
20:37 zakharyas joined
TimToady sure woulda been nice if the inventors of printf had figured out how not to duplicate the type system in the formats 20:38
dalek arVM/curly: 2f0cf28 | FROGGS++ | / (8 files):
add scdisclaim op

This way we can deserialize an serialization context (SC), throw the SC away, and then serialize the obtained object to another SC.		 20:39
brrt FROGGS - will fix :-) 20:41
FROGGS brrt++ # :o)
dalek arVM: 2694b49 | brrt++ | src/jit/emit_x64.dasc:
Fix format type error in JIT logging
 20:46
brrt that should do it, i'd think; i will admit to not testing if clang agrees
dalek MoarVM: 9f6fecd | brrt++ | src/ (4 files): 21:02
MoarVM: Add MVM_oops() function to panic with backtrace
MoarVM:
MoarVM: This allows us to panic while leaving a pretty backtrace for
MoarVM: debugging. MVM_panic() is better used for situations in which
MoarVM: we expect memory corruption, but there are still plenty of
MoarVM: situation where some invariant has been invalidated even
MoarVM: without memory corruption. We used to throw exceptions, but
MoarVM: they have the disadvantage that they may be caught and mistaken
MoarVM: for something else.
MoarVM:
MoarVM: This only adds MVM_oops() calls in the JIT, as I've most confidence
brrt and with that, i'm afk :-) 21:03
21:03 brrt left 21:16 FROGGS joined 21:42 FROGGS 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!