00:18 lizmat joined 01:01 vendethiel joined 01:48 ilbot3 joined 01:57 vendethiel joined 06:42 domidumont joined 07:34 zakharyas joined 09:42 brrt joined 09:59 zakharyas joined
dalek arVM/line_based_coverage_3: 83468b5 | (Daniel Green)++ | tools/parse_coverage_report.p6:
Break out percentage into its own column and add some JS+CSS to sort the table
 11:03
arVM/line_based_coverage_3: 641b736 | (Daniel Green)++ | tools/parse_coverage_report.p6:
Switch to the non-minified JS
arVM/line_based_coverage_3: c5b9ae3 | lizmat++ | tools/parse_coverage_report.p6:
Merge pull request #381 from MasterDuke17/line_based_coverage_3

Give percentage its own column and add some JS+CSS to make the table sortable
11:32 brrt joined
brrt good * #moarvm 11:33
one more question, and then i'm done
how long do the live range objects themselves need to live? 11:34
a): for the whole of the allocation scheme
b): just as long as my cursor is within their range
i.e. after spilling a live range, do i need to keep the descriptor arround 11:35
if i do a): then splitting the register allocation from register assignment is somewhat simpler 11:36
however, that may not really be a worthwhile goal anyway, because precoloring (assigning values to the place they are needed) needs to be coupled to register assignment anyway 11:37
12:02 vendethiel joined 13:06 brrt joined
timotimo brrt: i wish i knew the/an answer 13:45
brrt well, no reason to despair :-) 14:08
the safe answer is just to keep them arround 14:09
timotimo i'd like to take a few more baby steps toward building the deopt bridges
brrt luajit, of course, only generates them on demand 14:14
timotimo you mean the bridges? 14:20
brrt well, they call them side traces 14:22
but yes
anyway, what's keeping you from starting with a few baby steps :-0
:-)
timotimo dunno :\ 14:23
i'll be duplicating the guard instructions with versions that take a BB 14:24
there's so many of them :|
and i don't really know which are most common(ly hit)
brrt why not start with just one 14:26
timotimo right. i probably should
make a suggestion? :)
brrt the simplest one... sp_guardtype or sp_guardconc 14:29
timotimo if i'm not mistaken, i need an op for each kind of deopt we can do, right? to put at the end of the bridge? 14:30
but i'll know at spesh time which one i need to emit because there's the deopt annotations in the code belonging to the guard 14:31
timotimo puts a speshlog in front of him 14:32
359 sp_guardconc 14:33
42 sp_guardtype
34 sp_guardrwconc
now if only i knew which one gets hit more often ...
now for some debugspam :) 14:36
brrt hmmmm 14:37
timotimo 701148 guardrwconc b0rked
1273 guardtype b0rked
727 guardconc b0rked
brrt it depends on how you want to do it
timotimo would you have guessed?
brrt no, wouldn't 14:38
timotimo wait a minute
i actually want to build bridges for the least often taken paths
because every bridge i build moves unnecessary code out of the mainline
if i were to immediately build a second speshed version based on "this guard didn't hold. but let's assume all other guards still hold", *then* i'd want to take the most often taken guards 14:39
that's going to happen in the future, but i have no clue how hard that'll be 14:41
i think i'd have to do a full re-spesh of the original code and turn the guard into a regular branch that'll take execution into a "parallel universe" where i'll clone most of the BBs
brrt hmmmmm
ok, i may be naive, but.... 14:42
timotimo that sound like i'd be re-speshing fully every time i detect hotness on a new guard, and i'd be doing that parallel-world-clone quadratically
brrt i was under the impression that the goal was to take a basic block that had some move operations; prove that these moves or copies are unnecesssary after a guard; move the copies to a new basic block, and have the guard point to that bb? 14:43
so... why not do the proving thing first?
timotimo yes, that's the first milestone in this project 14:45
i'm getting far ahead of myself
brrt knows what that is like :-) 14:48
timotimo :D
there's another thing i'd really like to get into moar, but i don't know how to properly engineer it 14:49
sometimes we build guards based on logs where the logs "figured out" some property that we already knew based on our regular fact discovery mechanism
so we'll end up with something like a create op followed shortly by a guard 14:50
i don't remember where i saw that example
for some reason i couldn't just check for the flags at the point where the log guard tries to set up its facts, because the flags were just 0 ... or something like that?
brrt hmmm 14:52
i don't really know, to be honest 14:53
timotimo right, i'd have to find the example again 14:54
i'm really not sure i want to be messing around with the deopt table :| 15:05
brrt no.. i'm not suggesting that you should 15:06
in fact, i'm not suggesting anything
timotimo oh, is it enough to just add a little annotation?
brrt i have no idea to be honest
timotimo in fact, i can just duplicate the annotation that's in front of the guard op? 15:07
it seems like i'll just be able to rip out the annotation that belonged to the sp_guard* and put it in front of my sp_forcedeopt 15:12
so at least that part is kind of figured out
and Deopt All apparently only appears before invoke_* ops 15:13
AFK for a bit 15:35
15:41 domidumont joined
timotimo i think first i shall just turn sp_guardconc into sp_bridgeconc and immediately sp_forcedeopt 16:12
and see if anything breaks
16:16 domidumont joined
timotimo oh crap 16:17
i'm adding branches to the *middle* of BBs
that sucks.
hm. i can potentially insert the new BB into the linear order and make it less crappy that way 16:20
otherwise there'd be a crazy amount of jumps back and forth?
16:40 zakharyas joined 17:05 dalek joined, synopsebot6 joined 17:31 vendethiel joined 17:51 domidumont joined
brrt you'll have to split the basic block, that's for sure 17:51
i can't really say what the fallout of tha tis
timotimo hopefully nothing 17:53
if i make sure the linear order stays correct?
and inside the bridges we won't be throwing exceptions or anything 17:54
brrt hmmm 17:56
that is .... okay, but very, very, very fragile
timotimo oh? 17:58
could you elaborate? 18:03
brrt sorry, i'm somewhat busy 18:19
i can see how it makes sense to keep the linear order, so that you don't upset the inlining and deoptimization tables 18:20
on the other hand, that means you have to do that, forever
the alternative is that your forcedeopt gets a fixed number that ... for all i care, represents the original position of your guard 18:21
timotimo forever %) 18:22
that is just fixed by stealing the annotation
easy-peasy
because the annotation has the data in it, as far as i can tell
brrt no upsetting of tables at all; it's outside of the range of the true code, but who cares 18:23
because after the bridge, you're going back to the original code anyway
timotimo i only meant having the split put the two pieces a BB is split into in the original order 18:25
the bridge ought to go outside, of course. especially when we expect it to not be taken often 18:26
brrt ah, alright 18:27
right, fully agree
timotimo so, no worries about fragility? or doing something "forever"? 18:29
18:38 domidumont joined
brrt no, not really 18:43
in fact, the reverse
safe splitting of basic blocks is something we will probably need a lot of time
19:29 FROGGS joined
timotimo hm. vim over sshfs isn't working very well with all those modules i have, it seems like 21:10
21:11 Util joined
timotimo waiting multiple minutes to open this file ... ?!? 21:13
hoelzro o_O 21:14
psch ...use ed? 21:18
timotimo nah, i'm using vim inside ssh now 21:19
ugh. idx. not fun :| 21:23
for splitting BBs, i mean. i'll have to come up with a new index
well, i can just go through linear_next and +1 the idxes 21:24
they aren't supposed to be stable anyway
ugh, initial_pc is supposed to just be the cached instruction pointer at the beginning
and it's an uint, so i can't just set it to -1 21:25
i think i can just re-use the initial_pc from the original BB when i split 21:26
21:30 vendethiel joined
timotimo this is an ugly task 21:41
dalek arVM: bdff4dc | timotimo++ | src/spesh/manipulate. (2 files):
Implement a BB-splitting manipulation function
 22:30
timotimo ^- i bet it's b0rked beyond belief :)
i'd be pretty glad if someone would commet and/or fix ;) 22:46
a bit drained today, so not going to put in the "split basically everywhere" thing
22:50 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'Implement a BB-splitting manipulation function' 22:50
travis-ci.org/MoarVM/MoarVM/builds/142899784 github.com/MoarVM/MoarVM/compare/8...ff4dc9e3a3
22:50 travis-ci left
timotimo well, i should have at least tried to build it, seems like 22:56
dalek arVM: f9dad06 | timotimo++ | src/spesh/manipulate. (2 files):
fix signature of split_BB_at
 22:58
23:24 travis-ci joined
travis-ci MoarVM build passed. Timo Paulssen 'fix signature of split_BB_at' 23:24
travis-ci.org/MoarVM/MoarVM/builds/142905385 github.com/MoarVM/MoarVM/compare/b...dad06052ff
23:24 travis-ci left
timotimo good 23:25

Powered by Cro and the Raku® Programming Language.

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

Thank you!