00:09 Peter_R joined 01:56 colomon joined 02:12 colomon joined 02:17 colomon joined 02:19 ggoebel joined 04:45 raiph left 06:43 FROGGS joined
dalek arVM/even-moar-jit: e2d77b3 | brrt++ | src/jit/ (4 files):
Implement remaining declared tiles.

Some of these are not very well implemented as tiles, sinces tiles run in postorder mode by necessity.		 08:20
08:20 brrt joined
brrt good morning 08:28
09:31 rurban_ joined 12:07 brrt joined
dalek arVM/even-moar-jit: 9384c42 | brrt++ | / (9 files):
Add stub register allocator

Also add internal header to jit Makefile dependencies		 12:12
jnthn Sounds like we're getting closer to spitting out shiny machine code... :) 12:14
brrt yes, inching slowly closer :-) 12:17
hmm
i have something of an issue
or rather
i'm annoyed by something
basically, multiple parents refering to the same node might want different tiles for each 12:18
jnthn But since we have to come up with one tiling for the graph, we can't make two different choices? 12:21
brrt kind of 12:23
yes
actually, we can make two different choices
just have a buffer of tiles exactly as large as num_use 12:24
preferably allocated from one block
i'm not 100% sure if that's the right solution, though 12:25
i guess i'm saying, we can't make two different choices very easily, and it's not preferable either 12:28
jnthn Just make one that works for now, and defer worrying about making the optimal one? 12:30
Or is there a correctness issue too?
brrt correctness 12:34
let me give an example
hmm 12:35
ok, suppose i have something like (add $1 $2) and i tile that to (addl reg (load mem)); then i have another thing that does (sub $2 $3) and tile that to (sub reg (load mem)) 12:36
the (load mem) is implicit in the first tile
so no register is ever allocated for $2
but in the case of (sub reg (load mem)); i do need that value into a register 12:37
so i have to evaluate $2 twice; once as the memory address, and once as a value loaded into the register
indeed, given that, it'd be better to evaluate $2 to a register in the first place 12:39
but the tiler doesn't have enough info to make that decision (ironically) 12:40
because that information was lost when it was encoded into the ruleset... :-( 12:42
i'll be back a bit later :-) 12:43
jnthn OK. :)
And yeah, tricky problem :S
brrt i'' figure somthing out, i'm sure 12:44
timotimo oh 13:00
sounds like a little tripping stone
15:07 colomon joined 17:22 brrt joined
brrt ok, i have a potential solution 17:25
but it's not terribly pretty 17:26
and there is a separate problem
the solution, i htink, is a): to detect tile conflicht an b): in case of a conflict, generate a new node (with the same children), and apply the new tile to that node 17:28
and then link the 'second parent' to the new node
considering we do that bottom-up, we csn only end up with conflictless nodes 17:29
the problem, if anything, is that it's quite nonobvious to detect when we're conflicting tiles and when we're overruling a tile from a parent tile
jnthn We don't tag nodes that have been involved in a tile as we go? 17:35
brrt euh, it's more complicated than that, i think 17:38
or, my thoughts about it are more complicated
but tagging is probably part of the solution 17:39
hmmm
ok, i can explan; currently, the 'best rule' is downward-propagated from the parent rule 17:40
that's .. probably subtly wrong, but anyway
suppose i visit a node twice. suppose according to that node, which wants to evaluate to a register, i need to implement rule 5. suppose my first parent node wants to evaluate me to a label (it's possible). suppose then my second parent node wants to evaluate me to a register, again. 17:43
if i'm looking at my own node, then i'm altered register to label to register
but looking from the parents, i'm altering just twice... hmm 17:44
and from the perspective of the parent, i can see that the child has been revisited
so that i know i have a genuine tile conflict
ok, cool
fixed it ^^ 17:45
jnthn :)
brrt phew, that was a pickle
japhb Talking to the duck wins again, sounds like 17:46
brrt yes :-)
jnthn is happy to be brrt++'s duck :P 17:47
brrt is happy to have jnthn++ as a duck 17:48
or in other roles, really
my suspicion is that any performance improvement we're going to see this year in rakudo are going to come from glr :-) 17:50
japhb If you increase the hackability of the JIT and bring it to a more modern design footing, that vastly increases the chance of the JIT also considerably improving this year. 17:52
brrt hmm, yeah, i guess :-) 17:59
but it's probably going to take a while before it can really deliver 18:00
i mean, before we have a significant optimizer 18:02
and a properly large tile library
i'm actually quite curuious what kind of nice optimizations we'll find 18:11
18:26 zakharyas joined
timotimo so am i 19:31
let me loose :P 19:37
brrt :-) soon 19:39
timotimo I'm still not happy about how slow I am progressing with the parsing script 19:44
I will be on the road for another three hours at least
then, tents must be unpacked, air mattresses inflated, ... 19:45
jnthn The script that makes the pkgconfig/moar.pc can apparently explode and break people's Moar builds: rt.perl.org/Ticket/Display.html?id=125771 19:48
jnthn hopes timotimo will be a happy camper :) 19:56
'night, folks
dalek arVM/even-moar-jit: 4a83a08 | brrt++ | docs/jit (3 files):
Starting on JIT documentation
 20:24
brrt have fun timotimo
timotimo 2.5h left on the drive 20:43
20:48 TEttinger joined 21:06 nwc10 left

Powered by Cro and the Raku® Programming Language.

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

Thank you!