00:14 lizmat joined 01:19 oetiker joined 03:28 ShimmerFairy joined 06:14 rurban_ joined 06:52 zakharyas joined 07:16 brrt joined
brrt damnit, after my post yesterday i realised i've been doing best-rule calculcation wrong 07:16
and that i've no easy cheap way to fix it 07:17
07:34 FROGGS joined
brrt or maybe that i do have a way to fix it, but it's complex 07:52
TimToady the perfect is the enemy of the good? or was it the other way around... :) 08:14
brrt the animosity is mutual 08:31
but, i'd argue, this is a bit of an epic screwup
the basic problem is that in calculating the best rule given a ruleset for a given nonterminal symbol, i don't take the rules that generate its referent nonterminal symbols into account 08:39
which means the code generator should always choose the 'cheapest' rule on a local sense, meaning it disregards all the tree information, meaning it generates sucky code :-( 08:40
dalek arVM/even-moar-jit: 7efe6d8 | brrt++ | / (14 files):
Organise architecture-specific files

Provide preprocessor definitions in config.h to enable header file selection. All x64-specific files go into their own directory.		 08:53
brrt and the important corollary of my lament is that it doesn't have to, i just need to figure out how to calculate the real cost of a rule 08:54
given a ruleset, implying certain child rulesets, etc 08:55
TimToady just borrow Deep Blue
and teach it about CPUs instead of chessboards... 08:56
brrt i think that's called superoptimization, and it's awesome 08:57
but not very suited for just-in-time
jnthn Who'da thunk JIT compilation would be so full of funky problems... :) 09:21
dalek arVM/even-moar-jit: 45b6314 | brrt++ | / (4 files):
Move architecture definitions to header
 09:22
brrt well, ehm.... i kind of had expected a bit less :-)
jnthn :) 09:23
brrt but i guess that was pretty naive 09:24
you know what's also naive? an architecture-independent register allocator 09:29
09:46 FROGGS_ joined 11:10 rurban_ joined 11:38 Ven joined 12:01 Ven joined 12:30 brrt joined
brrt \o 12:33
JimmyZ o/ 12:38
brrt ok, i checked it out, and the minimum-cost table is wrong 12:50
which is... not life-shattering, but really annoying
12:51 zakharyas joined
dalek arVM/even-moar-jit: aa5b4a9 | brrt++ | tools/tiler-table-generator.pl:
Dump minimum-cost table

Visual inspection confirms my supsicion that the current optimum cost calculation algorihtm is way to simplistic, which I'd expect because it doesn't take implied costs into account. So that will require some calibration		 12:59
13:38 lizmat_ joined
brrt now what... 13:42
for some reason ARGLIST doesn't end up in the tile table, but i'm fairly sure we're writing rulesets for it alright 13:44
and now i know why 13:45
13:45 Ven joined
brrt regexes, they are a powertool 13:47
14:08 Ven joined 15:13 brrt joined 15:22 Ven joined
FROGGS o/ 15:37
hoelzro greetings FROGGS 15:41
15:41 Ven joined 16:14 brrt joined
dalek arVM/even-moar-jit: f871cdf | brrt++ | / (7 files):
Fix tiling so that we almost work through NQP
 17:16
brrt seems like i'll need a special if-void node type 17:17
brrt afk &
[Coke] brrt++ 17:31
17:40 lizmat joined 18:00 rurban_ joined
jnthn "almsot work through NQP" sounds like nice progress :) 18:11
18:14 colomon joined 18:19 zakharyas joined 19:00 lizmat joined 19:21 brrt joined
brrt \o/ we pass make test 19:28
(for nqp)
jnthn brrt: With le new JIT? :) 19:29
brrt the tiling part, yes :-)
jnthn Aha, OK :)
So a few more steps until it's doing the code-gen from the tiles?
brrt yes 19:30
there are two major difficulties left: one is register allocation (on the todo list since... ehm, early july i think) and one is branches, which isn't difficult conceptually but technically 19:31
and before we're really, really done, we need to add throwish and invokish in the mix, but that is conceptually quite simple and can mostly be copied from the old JIT
and then there is the issue of the minimum-cost table i talked about this morning 19:32
dalek arVM/even-moar-jit: 76a03fd | brrt++ | src/jit/ (6 files):
Add EITHER node to disambiguate from void IF

We can generate tiles for void IF just fine, but we can't disambiguate them for ambiguous tiles (CALL), so it's better to have a special void IF node which is now called EITHER.		 19:33
brrt jnthn: fwiw, i can state the problem this way: suppose i have a ruleset and a nonterminal, what's the best rule in the ruleset to implement that nonterminal? 19:34
my current implementation says: the cheapest rule that generates the desired nonterminal
but this disregards the information in the ruleset; because we have the ruleset we know something of the cost of the tiles it refers to 19:35
simplest possible case: (add reg reg) and (add reg (load mem)); the register-register addition is cheaper because it doesn't require a load from memory; but the only case we'll ever see these rules combined is when the load-from-memory is necessary anyway 19:36
so the fact that they're together implies that the cost of (add reg reg) is really (load mem) + (add reg reg)
see.. what i mean? :-) 19:37
i need to add the implied costs into the rule given the ruleset 19:38
and i think... it's possible inverting the trie might just work 19:39
jnthn Hm, so the costs are not so static :)
brrt well, i treat them as static at compile time. it's just that the tree information *implied in the ruleset state* should at least be calculated :-) 19:40
20:28 rurban_ joined
dalek arVM/even-moar-jit: 2390e0a | brrt++ | / (3 files):
Add tile logging, fix conflict resolution bug

Note to self: either change the names of MVMJitExprOpInfo and MVMJitExprNodeInfo to be more distinguished, or renember what they stand for.		 20:59
22:13 TEttinger 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!