03:07 orbus joined 05:47 brrt joined
brrt good * 05:50
but mostly morning
timotimo hey brrt! 06:08
brrt hey timotimo :-)
i've seen you've been busy
oh yes, i wanted to tell you
don't worry about doint sp_guardconc just yet 06:09
timotimo "oh btw you've been doing i tall wrong!"? :)
ah, ok
brrt nooooo that's not what i mean
timotimo :)
brrt do i come over often like that?
timotimo nope
not at all
early morning humor isn't exactly my specialty
brrt :-)
timotimo i was just suggesting these because they cause a crapton of bails 06:10
brrt yeah, i feel a bit guilty for making you do so much work
yes, well, the solution for that is actually simpler
timotimo haha
have you seen the bail statistics for a full nqp compilation?
brrt just make the tree a bit smalller and continue with the rest on the old-fashioned way 06:11
for example, the whole prepargs-to-invoke sequence
there is probably very little gain in making that exprtree
so when we see prepargs, we can just consnume the invoke, and when done with that, we continue to try and make a tree 06:12
(yes, i did see it)
timotimo hm, because invoke spills all registers anyway?
brrt how do you collect the logs of the whole thing
aye
and then jumps out, no less
timotimo i just set the jitlog to stderr and redirect the stderr output of the whole make process to a single file 06:13
brrt so even nonvolatilve callee-saved registers wouldnt help you
timotimo so there's a bit of redundant data for every single startup in there
brrt aha... clever
yeah
timotimo time for a shower
gt_i, lt_i, eq_i, ... these all want the flag-to-value node, right? 06:14
but other than that, i won't need to write a tile for them?
timotimo disappears right after writing a question
brrt they need new and fashionable tile implementations 06:18
other than that you're good
pypy got SIMD, many nice: pypyvecopt.blogspot.nl/2015/08/the-...-simd.html 06:27
(when will we get SIMD? some day, m'boy)
JimmyZ Christmas :P 06:31
brrt that is soon, in my opinion 06:33
ah, it uses numpy arrays to optimize 06:34
that is... hmm
still a pretty cool result 06:37
timotimo cool, simd 06:44
brrt breakfast & 06:51
06:53 zakharyas joined 07:11 brrt joined 07:49 lizmat joined 07:53 FROGGS joined
hoelzro moarning 07:58
nwc10 good *, hoelzro 08:01
hoelzro o/ nwc10
timotimo o/ 08:05
brrt good moarning, hoelzro 08:10
hoelzro o/ timotimo, brrt
timotimo o/ brrt hoelzro nwc10 08:18
tadzik hello hackathon! \o/ 08:37
masak hello hello hello \o/ 08:38
hoelzro ahoy tadzik 08:39
08:50 zakharyas joined 09:07 brrt joined 09:09 colomon joined 09:22 donaldh joined 09:34 Ven joined 10:15 Ven joined 11:05 Ven joined 11:13 colomon joined 11:22 Ven joined
moritz hi all 11:48
anybody want to d a MoarVM release?
would help me with my rakudo + nqp release 11:49
11:52 brrt joined
dalek arVM: e5753cc | moritz++ | docs/ChangeLog:
Add a Changelog entry

I am not qualified to infer any other user-visible, noteworthy changes from `git log`. Help would be appreciated :-)		 11:53
11:59 Ven joined 12:17 rarara joined
dalek arVM/even-moar-jit: 82bff79 | brrt++ | src/jit/ (8 files):
Fix spilling, IF assignment, and other things

Crash somewhere anyway		 12:52
timotimo hey brrt 12:56
how good are you with the GC and roots and such?
i may need your help :|
because this problem is driving me mad
hold on, i'll push a branch 12:57
brrt hey timo 12:58
not.. terribly good
but i'll look, sure
timotimo thank you so much :) 12:59
brrt yw 13:00
of course :-)
dalek arVM/nfa_to_statelist: 061b0e0 | timotimo++ | / (8 files):
implement nfatostatelist

isn't correct yet; something about temp roots is wrong		 13:01
timotimo there's an nqp branch to go with that 13:02
when building nqp, we'll reach a place where we segfault because one of the MVMCollectable **'s in the temp rootlist points at a bogus address 13:03
and for the life of me i can't figure out the problem; it may be staring me right in the face, though
brrt wait a minute, i'll be back 13:05
timotimo i've tried to figure out which exact root it is that breaks, but it didn't help make more sense out of it (even after interpreting the stack both forwards and backwards) 13:23
jnthn timotimo: Um 13:24
+ MVM_gc_root_temp_push(tc, nfa_obj);
That needs to be &nfa_obj, iirc
JimmyZ timotimo: MVM_repr_push_o(tc, edgelist, MVM_repr_box_int(tc, MVM_hll_current(tc)->int_box_type, act)); # you can't box here after push edgelist to the stack 13:26
timotimo jnthn: oh! is that what i'm doing wrong? 13:31
translating from the macro to macroless ... of course i forgot to put the & in there, too
jnthn Well, and what JimmyZ said to :)
timotimo JimmyZ: please elaborate 13:32
jnthn timotimo: edgelist will be on the C stack and MoarVM doesn't know about that, so if box_int allocates then edgelist will be out of date 13:33
timotimo right, but i put edgelist onto the temporary stack right before that
right after allocating it i pushed it onto the stack 13:34
JimmyZ the gc will update the pointer of edgelist if it moves
timotimo yeah 13:35
that's my expectation
JimmyZ thus it will be out of date
timotimo but i've rooted "&edgelist" before i did that allocation 13:36
so the gc will update the value on the stack for me
JimmyZ the c stack means it on the reg of cpu
and if gc update the memory , the reg is out of date
timotimo fortunately i've passed the address of the value to some other place and such
the compiler mustn't hold the thing just in a register 13:37
and if the gc has run in the mean time, that's a whole bunch of frames on the stack that've probably overwritten the registers anyway, no?
hm 13:38
i think i see what you mean, though
because the return value of the allocation immediately gets used and perhaps the c compiler doesn't properly restore the value?
the only thing to "fix" it that i can think of is putting the allocation a line before that and assign the result into a var 13:40
but that'd be the very same as far as the compiler's concerned 13:41
anyway, i make it through a full rakudo build with this
now i'll just have to ask jnthn how exactly we can use the nfa_to_statelist instead of deserializing the statelist arrays 13:42
dalek arVM: 59ee270 | (Ben Tyler)++ | src/math/bigintops.c:
Fix memory leak in MVM_bigint_mod.

The temporary bigints created by forcibly upgrading to bigint should always be cleared, rather than only in case of div zero.		 13:48
arVM: fed17a3 | lizmat++ | src/math/bigintops.c:
Merge pull request #235 from kanatohodets/master

Fix memory leak in MVM_bigint_mod.
JimmyZ timotimo: re 'fix' ,yes
FROGGS btyler_++ 13:56
timotimo JimmyZ: will it actually make any difference at all? os was the yes for "that'd be the very same"? 13:57
[Coke] btyler++ 14:01
JimmyZ timotimo: it is different 14:08
hoelzro btyler++ # num_leaks-- 14:24
timotimo JimmyZ: if it's actually wrong, neither the build nor the spec tests provoke a crash from that 14:34
JimmyZ timotimo: it won't crash if the allocation doesn't trigger the gc 14:41
timotimo that's why i run a whole spectest 14:42
to provoke a gc trigger in the middle of that
i could just do it 10000 times in a loop
then it's bound to hit every allocation in there at some point :P 14:43
jnthn timotimo: You can also make the nursery tiny 14:46
timotimo doing it 100k times every time a nfa gets initialized and it's taking its sweet time, but it's not crashing 14:47
14:59 Ven joined
JimmyZ timotimo: looks like you could use MVM_repr_push_i for from_to by allocate intarray 15:03
timotimo does it automatically box the int for me? 15:04
JimmyZ I think intarray could avoid box the int . 15:05
if it use intarray type 15:06
timotimo oh, we can do that, but only for from_to
that'd be acceptable
JimmyZ yes
timotimo i'll have a look at that later; right now i'm trying to patch NQP a bit 15:07
JimmyZ and save size
timotimo aye
and less indirection
15:21 brrt joined
brrt ok, i have ugly news 15:54
hmm
not terribly ugly, now that i think of it
the mem abstraction has to go
also, i have an ugly double free in dasm, and i'm not sure how it happens 15:56
[Coke] m: sub foo($alpha: $beta) { say "$alpha: $beta" }; foo 42, "OH HAI" 15:57
camelia rakudo-moar 47ddca: OUTPUTĀ«Cannot bind to non-existing object lexical 'self'ā¤ in sub foo at /tmp/KjmNYqPisE:1ā¤ in block <unit> at /tmp/KjmNYqPisE:1ā¤ā¤Ā»
timotimo i don't think i know what you mean by mem abstraction 16:01
brrt basically, it was the idea that rather than have 2 different tiles per memory access mode, i'd use just one for loading-from-memory 16:04
that doesn't work out, at all
timotimo oh
isn't that what we wanted register selection for in the first place?
or is that only "if you use the register-form of this x86 opcode, the register can come from a variable"? 16:05
[Coke] m: say (^10).map: { $^n * 2 + 1 }.perl
camelia rakudo-moar 47ddca: OUTPUTĀ«Cannot call map(Int: Int, Int, Int, Int, Int, Int, Int, Int, Int, Str); none of these signatures match:ā¤ ($: Whatever, *%_)ā¤ ($: &block, :$label, *%_)ā¤ in block <unit> at /tmp/8ntmTxcOZ8:1ā¤ā¤Ā»
[Coke] whoops, wrong window. 16:06
timotimo brrt: so we need to duplicate almost every tile now? 16:22
brrt nah, only the tiles that have mem refs 16:27
and what is more, these have already been written, they only need to be split apart 16:28
timotimo ah
that doesn't sound so doom-ish, gloom-ish
brrt no
timotimo cool
brrt but it requires a bit of a value structure rethink
and i'm hoping the tile table doesn't explode
in size
timotimo mhh
also, i'm still supposed to write new tiles for eq_i, ne_i, lt_i and friends if i understood correctly 16:29
brrt well, that's not your job, you know :-P 16:30
but if you want them, then yes
timotimo well, now i want the jit to get to a good place faster :P 16:32
and my other task is pretty frustrating and i'm not making progress at all 16:33
brrt ok, well, i'll try to explain it as quickly as possible, as i'm due to have dinner in < 10m
timotimo oh, cool 16:34
brrt tiles are declared in src/jit/$platform/tiles.list
timotimo mhm, i've got that open now
brrt the tile code is declared in src/jit/$platform/tiles.dasc
which is dutifully included from emit.dasc
also, tile names are predeclared in src/jit/$platform/tile_decl.h 16:35
tiles are simply declared with s-expresion synatx
timotimo ah
brrt first word is tile; second word is name of tile rule function; third is a list that is matched, fourth the terminal that is yielded, fifth an approximation of the costs 16:36
i have to revisit cost calculation someday, so don't worry about that
the key is, i think, the terminal
reg should be used for those things that yield a register
the eq,ne, lt, etc nodes do not yield a register 16:37
instead, they yield a flag
a condition code on which you can jump, or which you can convert into a byte value 16:38
(the last using the setCC instructions)
timotimo ah, ok
brrt setnz, setne, setl, setge, etc
timotimo right
brrt declaring a tile is the simple bit 16:39
for e.g. the equal operation:
timotimo would i build lt_mem and lt_reg? or lt_mem_mem, lt_mem_reg, lt_reg_reg?
brrt (tile: equal (eq reg reg) flag 2)
forget about mem
:-)
timotimo OK
brrt if you wished, you could do (tile: equal_addr (eq reg (load (addr reg))) 16:41
but, not important
the important bit is implementing tiles in tiles.dasc
because the tile rule declaration is quite long, it's easiest to use the MVM_JIT_TILE_DECL(tile_name) macro 16:42
timotimo i did that
brrt you have access to the compiler, the tree, the node, the node arguments, and most importantly the *values array
timotimo right; does the values also include the thing i'm supposed to write to? 16:43
brrt this values array refers to the MVMJitExprValue associated with all nonterminals in your tile
timotimo because zr_reg for example accesses values[1]->u.reg.num
brrt yes, that's actually in values[0]
timotimo k
but since i emit a flag, i ignore values[0]
brrt except, in this case, since you're writing a flag, your not writing to that
writing a tile that yields a flag
yes 16:44
timotimo do i need to have a 2x2 switch for sizes of both registers? o_O
brrt how would you compare the equality of one size with another? 16:45
timotimo right
how bothersome :)
brrt values[0] holds the size of the comparison :-)
values[0]->size
timotimo um, wha?
the size of the target register?
but that's supposed to be the flag?
brrt size of the computation, i'd.. think... but i'm not sure 16:46
timotimo oh, is it guaranteed both operands are the same size?
brrt damnit, i know what i did wrong 16:47
no, actually not
but they should be, and if not i should error out
timotimo ah, ok
so none of my bizniz 16:48
brrt afk for now
timotimo kthx! 16:49
hm, except ... test sets the flag, all i can do for equal is ask for a specific condition to be put into a register value, no?
i mean, there's one branch operation for every variant: equal, not equal, greater than, greater/equal, ... 16:50
so my tile would have to also match a following branching op, or alternatively return a register
[Coke] nqp::shell complains it requires 7 operands. Not in the docs. :P 16:51
ww. 16:52
FROGGS ups, I forgot to update its docs :S
17:43 Peter_R joined 18:33 arnsholt joined 18:47 Peter_R joined 19:06 Peter_R joined
timotimo brrt had a very long dinner so far 19:11
19:14 Ven joined 19:53 Peter_R joined 20:14 brrt joined
brrt back 20:14
yeah, it's not really fair of me to dump that in your hands
the template for eq_i and friend basically looks like (flagval (eq $1 $2)) 20:15
maybe even
(convert (flagval (eq $1 $2)) 1 reg_sz)
timotimo hah
brrt or
20:16 nebuchadnezzar joined
brrt (flagval (eq $1 $2) reg_sz) 20:16
something like that
i don't know yet
timotimo am i mistaken that the only comparison op that generates a flag on x86 is "test"?
brrt yes, your are mistaken
*you
timotimo aha!
brrt the other one is cmp
timotimo oh
brrt test is boolean and -> flags
cmp is integer sub -> flags 20:17
make sense?
timotimo right
but how do i create eq and friends from that?
and reg_sz is just the size a register has?
brrt yes 20:18
but keep in mind i haven't actually gotten that far :-)
timotimo AFAIK, i set the flag register with test and then i use different operators to turn flag into bytes and depending on *that* operator i get the difference between eq, ne, lt, gt, le, ge 20:22
so if i'm not mistaken, the tile for eq and friends has to actually generate a register, not a flag
brrt well, that would be a logical thought, but no 20:24
it's more convoluted than that :-)
basically, if you check out MVM_jit_emit_conditional_jump, you see what i'm trying to do there 20:25
the basic rule is; the flaggy tiles generate a condition-code, and jumpy or flagval tiles use that condition code, and dispatch on the basis of the operand that generated the tile 20:26
this is feasible only because there are only a few tiles
eh, nodes, that generate flaggy conditions
timotimo why don't it logic! 20:29
but i understand very well why you make that design
otherwise it'd have to test -> to byte -> to flag -> to branch
that'd suck
would that mean eq, ne, lt, le, gt, ge would all have the exact same implementation for the tile itself? 20:30
brrt aye 20:31
thats exactly what that means 20:32
timotimo then i'll make it a macro :P
brrt no
:-P
timotimo why not?
oh
i meant a #define
20:33 TEttinger joined
timotimo you meant MVM_jit_emit_conditional_branch btw :) 20:34
brrt yeah, i understood you meant a #define. wouldn't work because dynasm runs before the c preprocessor
actually 20:35
you could do a #define in this case
timotimo :D
how does it map my tiles to the flag values from that enum? 20:36
brrt the node name? the answer is prosaic 20:41
we read it directly from the tree 20:42
timotimo ā€¦ yeah, but how do i bring my tile and MVM_JIT_LT to coincide to the same value? 20:44
brrt not sure what you mean now 20:47
or, what do you want to achieve :-)
timotimo well, when i implement the tile for eq 20:54
how does the code that emits the conditional branch
how does it know that my tile for eq is the tile for eq?
brrt well, it takes the value of it's first child node
and switches on that 20:55
it's easier if i implement it myself
:-)
timotimo i think so, too x_X
because what is that value it switches on? the estimated cost value?
dalek MoarVM: a2e4c65 | paultcochrane++ | src/core/interp.c:
MoarVM: Remove unused assignment
MoarVM:
MoarVM: clang's `scan-build` noted that the value of `orig` returned from the call
MoarVM: to `MVM_frame_dec_ref()` wasn't used after the assignment. This change
timotimo i'll head over to the hotel 20:56
i'm quite tired
and i'm not being productive at all over the last hours :(
20:56 dalek joined
brrt see also the when_branch tile 20:56
sleep well :-)
timotimo yes, i see that
brrt dude, it's, nearly 23:00. you've helped a lot :-)
timotimo but still
where does the value "MVM_JIT_LT" come from when i build the tile? 20:57
that's been my question all this time
i have to somehow put that into my tile
20:57 colomon joined
brrt no, i don't think you do :-) 20:57
see the tile tree *matches* the lt, or eq, or whatever 20:58
timotimo in that case, there must be some magic that i haven.t been able to see
oh!
OH!
brrt it implmeents a rule that executes cmp foo, bar
timotimo so the lt has already been put in there by a template or a macro
brrt yes
timotimo my lord. i'm dense 20:59
off to bed i go
tomorrow i might try again. or find something else to do
brrt the template insert the eq/lt/gt etc. the tile matches it. the flagval dispatches and stores the right cc
timotimo like zmq binding and then ipython/jupyter kernel implementation
gnite and good luck!
brrt who cares about these things :-P
yes, you too
timotimo ptc does :) 21:00
brrt fair enough 21:04
there is a weird, weird mov in my code
i wonder where it comes from 21:05
dalek arVM/even-moar-jit: 3f55d74 | brrt++ | src/jit/ (2 files):
Negative offsets mean jump out

If you pass a negative offset to the dynamic label facility, dynasm will crash with a malloc corruption error. As it should.		 21:08
21:10 colomon joined 21:12 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!