01:48 ilbot3 joined 05:57 brrt joined
brrt \o 05:59
06:05 leedo joined 06:21 FROGGS joined
brrt jnthn: can i perchance look at the not-so-jitted frame 06:37
nwc10 HEAD whisky-expert24.at/ 06:38
301 Moved Permanently
Location: www.expert24.com/whisky/ 06:39
nwc10 needs to update some more regression tests. :-)
brrt jnthn: having .list generate an iterator memoizing into an array is really sensible. having it so close to .List which generates a List (which isn't size-extendable) may be a tripup 06:44
as in, List generates something that is shape-immutable? (that's contrary to python, btw, where a list is a ... dynamic array with rather finicky semantics, and an array is a semi-dynamic array with even finickier semantics) 06:47
btw, github making comments light gray is not the best possible UX 06:48
hmm 07:06
seems like i'll be failing to keep dasm_proto.h out of the list of all headers 07:07
or, not 07:09
ha ha 07:20
07:28 rurban_ joined 07:54 zakharyas joined 08:03 TEttinger joined 09:28 brrt joined
FROGGS src/jit/graph.c:1603:34: warning: initialization makes integer from pointer without a cast [enabled by default] 09:49
{ MVM_JIT_LITERAL, { NULL } } };
^
src/jit/graph.c:1603:34: warning: (near initialization for ‘args[3].v.lit_i64’) [enabled by default]
10:57 brrt joined
dalek arVM: cb95c6b | brrt++ | src/jit/graph.c:
Fix warning in jit graph, FROGGS++
 10:58
FROGGS \o/ 11:00
brrt it's odd how assigning a literal 0 to a pointer value is ok and assinging NULL to an integer is not 11:01
jnthn Really
I'd have thought both would have counted as wrong level of indirection warning
FROGGS well, a pointer is a numeric value but a numeric value might not be a pointer
brrt in gcc, at least 11:02
which is always happy to please :-)
11:56 brrt joined 13:01 LLamaRider joined 13:58 rurban_ joined 14:04 brrt joined
brrt hmm 14:07
you all have not been able to actually *run* even-moar-jit for a while now :-( 14:08
brrt is going to fix that 14:19
15:10 Ven joined 15:55 FROGGS joined
timotimo o, cool! 15:59
but what exactly does that even mean? 16:01
16:05 zakharyas joined 16:45 zakharyas joined 17:28 kjs_ joined
dalek arVM/even-moar-jit: 53ce016 | brrt++ | / (5 files):
Add support for 'destructive' templates

Some opcodes prefer to write directly to vm memory (e.g. atpos and friends, exception result addresses). So we should support that and not insert a tree value for these nodes.		 17:40
arVM/even-moar-jit: 4e0326c | brrt++ | src/ (12 files):
WIP - Tile implementation
arVM/even-moar-jit: 98d76bb | brrt++ | src/jit/ (8 files):
Temporarily disable tiles to build a moar that runs
17:40 brrt joined
brrt timotimo: that i was, or am, stuck in limbo there it wasn't possible to run moarvm, thereby not being able to check if my work makes any sense 17:43
timotimo ah 18:04
brrt hmmm 18:18
i'm ambivalent with regards to labels 18:19
internal labels to the expr tree, that is
the best solution, i think, is to add a facility to allocate more labels at once 18:20
that's easy enough to implement :-)
but... but 18:26
i'd need two passes 18:31
one to count the ifs and whens
and one to fill them in with labels
19:44 brrt joined
dalek arVM/even-moar-jit: e58d670 | brrt++ | src/jit/ (2 files):
Add call tile grammar
 19:52
arVM/even-moar-jit: ff279dd | brrt++ | src/jit/ (6 files):
Wrap dasm_State in MVMJitComiler structure

This changes function signatures, but is not very exciting otherwise.
jnthn so boredom 20:07
brrt++
20:09 colomon_ joined
brrt :-) 20:13
(the goal is that the online register allocater and the assembler can be packed together) 20:14
an offline register allocator, if any, can work in a preparation step 20:15
jnthn: i would like some advice on something on which i'm a bit ambivalent 20:21
it's about jit labels
currently they're implemented as an array of void*; you add a pointer to something, and it checks if that pointer already exists 20:22
jnthn *nod* 20:23
Yeah, I think I encountered that a while ago when fixing an exception handler/inlining bug
(it was fine they were that way for fixing the issue)
brrt that's not wrong, per se, but i'm encountering the following
it's not safe to use pointers internal to the tree nodes, because the node buffer is realloced, and thus allowed to move 20:24
e.g. i can potentially, within the same graph, allocate the same block, and assign the same label to different nodes
this sucks, obviously 20:25
jnthn yes, fail
Does the node buffer ahve to be realloced?
brrt now during the analysis phase, the nodes are typically not added, therefore the block does not move, therefore i should be able to get away with it
jnthn As in, do you depend on contiguous allocation of the things?
brrt yeah, unfortunately
jnthn OK
Figured you must have a reason to not just spesh_alloc the things 20:26
brrt i have a chain of reasons :-)
spesh_alloc cannot realloc
jnthn Right, by design :)
So we can be free to take pointers to nodes where we like in a spesh graph and feel safe :) 20:27
And so we can trivially free memory later
But I can see how that isn't the best way for everything.
brrt making the tree nodes buffer contiguous allows me to serialize it as integers and use indices, and that's really helpful during tree construction 20:28
it's funny. i think we both made a different tradeoff, based on the fact that bytecode->spesh graph is an expansion, and spesh graph->expr tree is a lowering 20:29
(the expansion adds and records but does not change the form of the code, i mean) 20:30
well, that's not even entirely true, but still
so, moving pointers and labels, bad 20:31
two solutions
a): we get away with this, because analyze doesn't ever move the tree. if we ever want to rewrite something and add an if/when, we move the labelling to a phase wherein nodes are guaranteed not to move 20:33
a is clearly brittle
b): we add a functionality to allocate a bunch of labels together, count the labels required, and acquire them based on the identity of the expr tree object itself. since this does not move, we have a stable base of identity 20:34
b is not very difficult to implement, but it requires a good look at the labeling 20:35
c): we use local labels only within an expression tree; an approach that does not scale (local labels do not need to be declared) 20:36
b is clearly also sensitive to time-of-labelling 20:37
that gives me an idea, though 20:38
we use a, but we do it at compile time
jnthn Do the labels have to be identified by pointers to to something?
brrt i.e. add preorder entry
well, no, that's mostly useful to distinguish different objects from one another 20:39
and that's useful to distinguish e.g. instructions from basic blocks
there are other ways to do that, i think 20:40
hmm 20:42
i like the 'do it at compile time' solution
all it requires is a high-water-mark 20:43
it's robust to optimizations, moves
dasm supports it 20:44
ok, i'm happy
20:44 kjs_ joined
jnthn \o/ 20:45
brrt :-) sometimes all it requires is a bit of puzzling 20:46
now for the real challenge
i want to... never mind 20:47
the if-all case: jump over a block if any is false (or if-any: jump to block if any is true) 20:48
but that's also doable 20:49
by propagating the allocated label downward :-)
ok, that's enough puzzles for tonight 20:50
see you tomorrow! 20:51
jnthn brrt: Rest well! 20:53
brrt: See you tomorrow...I'll be doing Perl 6 stuffs tomorrow again also :)
brrt :-) awesome
jnthn "Korr för Pearl timmar i maj 2015" *snort* 20:54
jnthn wonders where between him and the accountant the spelling went wonky :)
21:21 pyrimidine joined 21:59 TEttinger joined 22:15 kjs_ 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!