01:00 btyler joined
dalek arVM: 7e3f970 | jimmy++ | src/ (2 files):
Use MVM_platform_unlink on Win32, which is more CJK-friendly
 01:09
01:10 FROGGS_ joined 01:19 woosley joined 01:51 TimToady joined 01:52 nwc10 joined, japhb_ joined, lee_ joined 02:03 daxim joined 04:18 hoelzro joined 06:42 FROGGS joined 06:45 zakharyas joined
nwc10 good UGT, * 08:24
FROGGS morning nwc10 08:28
JimmyZ++ # I forgot about unlink :/
10:23 odc joined 12:02 btyler joined 12:06 zakharyas joined
nwc10 jnthn: with that first i16 fix, NQP builds on PPC64, but Rakudo bombs out like this during the setting: 12:50
Stage mbc : At Frame 2027, Instruction 839, op 'getlexstatic_o' has invalid number (1) of operands; needs 2. at gen/moar/stage2/QAST.nqp:5082 (/home/nick/Sandpit/moar-g/languages/nqp/lib/QAST.moarvm:assemble_to_file:13)
I don't know where to start looking for the cause. It still happens with MVM_SPESH_DISABLE=1 12:51
FROGGS I think it is good that it also happens when spesh is disabled 13:02
nwc10 it is and it isn't
if it only happens with SPESH, I know where to start looking
FROGGS yeah, true :/ 13:04
hmm, we have duplicate code to do read_int32 and friends in bytecode.c and serialization.c 13:14
nwc10 I noticed this 13:18
IIRC there's duplicate writing code too 13:19
FROGGS yes, and I'd need read_ref in bytecode.c, but it looks like pain to get it :o(
jnthn nwc10: That error comes from src/mast/compiler.c. It may be bogus (the data structure is fine) or it may be that the data structure is wrong (e.g. it really does only contain one operand) 14:05
dalek arVM: 024b994 | jimmy++ | src/spesh/optimize.c:
Fixed MSVC build
 14:11
nwc10 jnthn: I'd located the source of the error, and checked that it wasn't getting confused by 64 bit values being truncated, but it wasn't, and that's where I got stuck 14:14
I didn't try figuring out if the data structure is OK, and the C code is confused
14:19 jnap joined
jnthn Well, it should have 2 args. 14:25
And thing is, asking how many it has is just an elems call which really should work out. 14:26
timotimo jnthn: got a suggestion what i could look at to figure out what exactly prevents get_i/get_s/get_n from being speshable? 14:52
more precisely: i know it won't do it because we don't know the type at spesh-time, but maybe there's a way to ensure that? 14:53
jnthn Well, the facts dump could be wroth a look
(that is now dumped after the CFG)
timotimo .o( like a global flag that tells us if there even is a second class with repr p6int/p6num/p6str)
FROGGS hmpf, I'd need write_ref in compiler.c also... 14:56
jnthn um...? 14:57
FROGGS jnthn: you know, I should attach the label's object to a handler, not its mem address, so all is safe in case it gets moved
but I can't write the ref, nor read the ref because compiler.c/bytecode.c only has read/wrint_int* stuff 14:58
write*
serialization.c has what I'd need, and also duplicates of the read/write_int* functions
jnthn Uh yes, well I'm happy when the code stops people making architectural mess :P
They're decoupled for a reason. 14:59
FROGGS ahh, so we need three version of memcpy_endian()? :o)
jnthn No, I'm pretty sure if you want to call write_ref in compiler.c then soemthing is happening that I don't want. 15:00
JimmyZ FROGGS: I'm trying removing [read|write]_int[16|32], but blocked by x84 build problem
FROGGS jnthn: ahh
jnthn FROGGS: If you put the label statically in the handler, will it not make issues for recursion and the map situation?
FROGGS jnthn: I'm not putting the label in a handler in case it is about map 15:01
putting in*
err, no, was correct as I wrote it :o)
(kinda)
in case for map (aka nqp::handle) the handler is always run, and rethrows if we have the wrong label 15:02
in case of while loops for example, we always have new handlers, so I attach the label to it 15:03
JimmyZ >moar.exe!shift(MVMThreadContext * tc, MVMSTable * st, MVMObject * root, void * data, MVMRegister * value, unsigned short kind) č”Œ 55C moar.exe!MVM_interp_run(MVMThreadContext * tc, void (MVMThreadContext *, void *) * initial_invoke, void * invoke_data) č”Œ 4053C moar.exe!MVM_vm_run_file(MVMInstance * instance, const char * filename) č”Œ 165C moar.exe!main(int argc, char * * argv) č”Œ 165C moar.exe!__tmainCRTStartup() č”Œ 240C 15:06
FROGGS I mean, I can do the same for 'while' as we do for 'map', but that means that we run all handlers that are about labels, and rethrow in most/all cases
JimmyZ argh
jnthn: gist.github.com/zhuomingliang/02eb...6f62e3bb23 15:07
timotimo jnthn: maybe you have another idea for something i could try to spesh?
now that i kinda sorta know how it works :) 15:08
JimmyZ turns out it's easy to get debug info by using static build :P
looks target is null 15:11
*looks like
jnthn Will have a look later; decommute & 15:13
dalek arVM/cleanups: 98f54f7 | jimmy++ | src/6model/ (5 files):
Removed [read|write]_int[16|32] code from serialization
 15:29
JimmyZ jnthn: Would you mind I merge it? 15:33
15:35 rurban_ joined
timotimo hm. maybe my set removal code is having problems with deopt? 16:10
since i think the code it emits seems right 16:13
it crashes right after visit_var gets specialized and the diff seems correct at least
gist.github.com/timo/49014d9c469d85ed7350 - would this be wrong? 16:32
16:32 FROGGS joined
timotimo see how the set + decont turns into one set 16:33
i don't even know if that's where it goes wrong, though 16:34
this is hard to debug :(
FROGGS jnthn: so, you want me to change exception handling so that blocks with labels always run their exception handlers?
pro: we wouldn't need to find a way to write/read that label object, contra: we can't skip handlers like we skip when it is the wrong category 16:35
17:50 jnap joined
nwc10 jnthn: for the annoying PPC64 "only 1", it does seem that the MVMArray genuinely has only 1 element 17:59
(gdb) p body->slots.o[0]
$11 = (MVMObject *) 0x33be02f0
(gdb) p body->slots.o[1]
$12 = (MVMObject *) 0x0
18:07 timo joined
jnthn nwc10: What's body->elems? 18:19
nwc10 1 18:20
says gdb
and says the C logic
jnthn Yeah...
OK, so the thing was wrongly constructed... 18:21
wtf...
nwc10 so everything is consistent at the C level, it seems.
yes, wtf
I can give you two other patches that aren't wrong :-)
jnthn :) 18:22
jnthn should probably cook dinner before looking at much else :)
nwc10 yes, go eat
jnthn I decommaught via the pub, which had a 7% IPA for me to try... :) 18:23
nwc10 they are cruel to you
timotimo jnthn: feel at all like hunting my set optimization problem? 18:24
the code merges cleanly onto latest matser (though locally i rebased it onto master)
18:27 brrt joined
brrt \o #moarvm 18:28
i think i've figured out how dynamic labels work in dasm 18:31
FROGGS hi brrt 18:33
brrt hi FROGGS 18:39
18:48 jnap joined
timotimo panda explodes in sp_guardcontconc 19:05
when trying to compile Buialder.pm
it seems like the "check" object is null and we don't check for that 19:06
tadzik timotimo++ #tracking it down 19:08
timotimo when adding a null check, i get the same read past the end of the string heap thingie 19:16
jnthn o/ brrt 19:26
timotimo: It seems like there's some corruption earlier on than that, then... 19:27
What's the op before the sp_guardcontconc? 19:28
timotimo how do i know? :(
what's the function to print a stack trace again?
from inside gdb?
jnthn Well, could look back a bit in the bytecode stream from the current location 19:29
brrt hi jnthn :-) 19:32
jnthn timotimo: uhhh 19:33
+ else if (override_second_argument == OVERRIDE_WITH_32)
+ write_int16(ws->bytecode_seg, ws->bytecode_pos, MVM_OP_const_i64_32);
There we write_int16 where the op reads 32 bits, no? 19:34
oh, no, I misread...
duh
oh... 19:36
It's the ops that are wrong
OP(const_i64_16):
GET_REG(cur_op, 0).i64 = GET_I16(cur_op, 2);
cur_op += 4;
goto NEXT;
gah, wrong again :)
*sigh*
jnthn is clearly a bit tired for this... 19:37
nwc10 go to bed?
jnthn Not quite tired enough for that :)
brrt wonders how he is ever going to cope with moarvm dev speed 19:38
nwc10 jnthn: OK, patch the first is paste.scsys.co.uk/372051 :-)
has no commit message. sorry
jnthn: Patch the second is paste.scsys.co.uk/372053 19:41
[Coke] moar doesn't like being run under a ulimit... got a segfault in the daily roast because of it. 19:47
S17-promise/allof.t
bumping up the required memory for rakudo.moar... 19:48
that clears 2 failures in roast; there are 30 other failures that are happening in S17-* 19:51
github.com/coke/perl6-roast-data/b....out#L2232
jnthn nwc10: Thanks, they look good. Will apply. 19:54
dalek arVM: 80cc8e6 | nicholas++ | src/spesh/facts.c:
Correct size of read from spesh log.

Should read a 16-bit integer from the operand, not a 64-bit one.		 20:19
arVM: 1f22a12 | jnthn++ | src/spesh/graph.c:
Ensure spesh_alloc aligns on platforms needing it.
jnthn d'oh, forgot to --author the second one :(
nwc10++, anyways
nwc10 don't worry 20:30
the alluded-to other thing for ARM is that P6opaque.c is fragile still. I noticed that with the first fix to get ARM working. 20:34
one part has
MVMuint32 cur_offset = sizeof(MVMP6opaque);
another part has 20:35
cur_alloc_addr = sizeof(MVMP6opaqueBody);
and at the time ("last week"), sizeof(MVMP6opaque) was a multiple of 8
brrt jnthn, i was wondering (wrt jit-ing)
nwc10 or at least, sizeof(MVMP6opaque) % 8 == sizeof(MVMP6opaqueBody) % 8
and I hoped that that didn't matter 20:36
but it does
brrt you perhaps know that as far as dynasm is concerned, it just returns a void* to some executable memory?
nwc10 because now you've fixed the O(n**2), the object header is larger, and the P6opaque stuff breaks alignment again
brrt anyway, you call into that as if it were a c pointer
nwc10 so I can get ARM to build like this:
} sc_forward_u;
+ void *hack;
maybe putting that in MVMCollectable is why it's swapping like a swappy thing 20:37
and it should have been in MVMP6opaque
brrt i /think/ it might be a good idea to pass something of (threadcontext, register base, etc) into that compiled code
jnthn brrt: Yes, and perhaps a "jump to" also. 20:38
nwc10 anyway, that's not the real fix. I think that the real fix is me understanding it better, and ideally needs a whiteboard
brrt that would change nothing except that the jit-ed code gets (e.g.) the pointer to MVMThreadContext always in the RDI argument
nwc10 but failing that, I'll try to have a think
brrt registe
jump to? as in, continuation address?
nwc10 but I think that the body always needs to have consistent alignment, and be assumed to start at offset 0
brrt hmm 20:42
nwc10 jnthn: I did this (patch) as a the pre-cursor to trying somethign else, and I *think* that it showed a nearly 1% speedup in setting time compilation: paste.scsys.co.uk/372090
but I'm not sure that I trust that
"nearly 1%" is too close to noise
(That was nearly 1%, as measured by dumbbench with 20 runs)
jnthn brrt: Well, like we were running JITted code, and then we had to fall back to the interpreter for something we call 'cus the callee isn't JITted yet, and when we return we need to re-enter the JITted code at a certain point 20:43
brrt: Or continuations, yes.
brrt: Or on-stack replacement. 20:44
brrt me is thinking
hmm 20:45
i think i see what you mean 20:46
we could use a stack that held in-jit-continuations
i.e. we'd pass a jit-ed function a pointer to MVMThreadContext and a pointer to the top of our stack 20:47
no, that won't work
:-(
ok, i think the basic question is this: how to compile a sequence of: native, interpreted, native (using the interpreted result) 20:49
jnthn brrt: fwiw, I think at least initially we really should have the JIT stick close to the frame structure that we use when interpreting (more) 20:50
deopt is a really important part of making this stuff all work out, and this does simplify it a bit.
brrt meaning all variables in reg_base? 20:51
jnthn Yes.
brrt that is not so different from stack allocation
:-)
jnthn Then *after* that works, we can start looking at points between which deopt or other falling out of JIT can never happen.
It's also a GC thing.
brrt ... yes 20:52
hmm
jnthn As in, if we trigger GC and there's a pointer sat in a CPU register...well...ouch :)
brrt and here i was with great hopes for register allocation
i see what you mean
jnthn I'm not saying we shoudln't do that eventually
I'm just saying I can see a bunch of things that make it rather hard. 20:53
brrt are gc runs concurrent? or - how are they triggered?
jnthn That is, we should probably walk before we try running.
No, not concurrent. Triggered when we allocate.
brrt ok
well.. long story short, when allocationg, i should call, when calling, registers must be saved 20:54
jnthn About interp -> native, I think in that case we could just point the interp at a "call into the JITted code" magical op
For native -> interp, I pondered that invocation always ends up calling something from the JIT that returns a memory address of JITted code to jump to in the event having it, and a NULL to indicate "no, not JITted, just return to the interp"
And since the interp is where we called into the JIT from, just having the JITted code to the equivalent to a C "return" at that point will be sufficient to find ourselves back in the interpreter. 20:55
That is to say, JITted code always runs a frame deeper than the interpreter.
brrt huh, jitting code without a 'ret' instruction is a way to crash real fast ;-)
agreed 20:56
jnthn Yes, but I mean more like
oh, I think you got it :)
brrt not entirely though
jnthn Oh :)
timotimo: I reproduced that SEGV in sp_garudcontconc locally
brrt suppose we have code: $foo++; $bar *= 2; # nicely jittable 20:57
jnthn Depending on the types of $foo and $bar... :)
brrt and then: my $quix := multi_call($foo, $bar); # unknown at spesh time?
and we then want to use the value of $quix in jit-ed code
how do we proceed then? 20:58
i suppose that since we're the ones generating the jitted code we might as well generate the interpreted code along with it
as in - we'd generate a sequence (on moarvm level) of: enterjit $first_portion; call $multi_call, $foo, $bar; enterjit $second_portion 21:00
jnthn Note that something like multi-call is actually a sequence of instructions at VM level
brrt i would suppose so, but you get the point :-) 21:01
i think i'll have to defer an actual strategy for later 21:02
jnthn Sure, what I'm (badly, 'cus I'm tired) trying to get accross is that I'm expecting that "make a VM-level call" will - at least initially - probably want to do something like invoke does today.
brrt continuation pointers seem like a good idea but i'm wondering what problem they solve that can't be solved by clever codegen
seems good to me :-)
jnthn Maybe it'd help if I wrote up what I've pondered so far on how the JITted/interpreted stuff could hang together. 21:03
Which you don't have to take as an absolute plan, of course. :)
brrt that would help
jnthn But it may make a few things clearer.
brrt i won't :-P but i could really use all forms of ideas 21:04
jnthn OK. I can't sensibly do it tonight; I slept badly last night (like, 4 hours) and taught all day today :/
brrt i'm thinking about a half-baked blog post myself :-) 21:05
brrt is off for sleep 21:07
21:07 brrt left 23:11 btyler 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!