[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 [11:03] MoarVM/line_based_coverage_3: 83468b5 | (Daniel Green)++ | tools/parse_coverage_report.p6: [11:03] MoarVM/line_based_coverage_3: Break out percentage into its own column and add some JS+CSS to sort the table [11:03] MoarVM/line_based_coverage_3: review: https://github.com/MoarVM/MoarVM/commit/83468b54ee [11:03] MoarVM/line_based_coverage_3: 641b736 | (Daniel Green)++ | tools/parse_coverage_report.p6: [11:03] MoarVM/line_based_coverage_3: Switch to the non-minified JS [11:03] MoarVM/line_based_coverage_3: review: https://github.com/MoarVM/MoarVM/commit/641b736f94 [11:03] MoarVM/line_based_coverage_3: c5b9ae3 | lizmat++ | tools/parse_coverage_report.p6: [11:03] MoarVM/line_based_coverage_3: Merge pull request #381 from MasterDuke17/line_based_coverage_3 [11:03] MoarVM/line_based_coverage_3: [11:03] MoarVM/line_based_coverage_3: Give percentage its own column and add some JS+CSS to make the table sortable [11:03] MoarVM/line_based_coverage_3: review: https://github.com/MoarVM/MoarVM/commit/c5b9ae3621 [11:32] *** brrt joined [11:33] good * #moarvm [11:33] one more question, and then i'm done [11:34] how long do the live range objects themselves need to live? [11:34] a): for the whole of the allocation scheme [11:34] b): just as long as my cursor is within their range [11:35] i.e. after spilling a live range, do i need to keep the descriptor arround [11:36] if i do a): then splitting the register allocation from register assignment is somewhat simpler [11:37] 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 [12:02] *** vendethiel joined [13:06] *** brrt joined [13:45] brrt: i wish i knew the/an answer [14:08] well, no reason to despair :-) [14:09] the safe answer is just to keep them arround [14:09] i'd like to take a few more baby steps toward building the deopt bridges [14:14] luajit, of course, only generates them on demand [14:20] you mean the bridges? [14:22] well, they call them side traces [14:22] but yes [14:22] anyway, what's keeping you from starting with a few baby steps :-0 [14:22] :-) [14:23] dunno :\ [14:24] i'll be duplicating the guard instructions with versions that take a BB [14:24] there's so many of them :| [14:24] and i don't really know which are most common(ly hit) [14:26] why not start with just one [14:26] right. i probably should [14:26] make a suggestion? :) [14:29] the simplest one... sp_guardtype or sp_guardconc [14:30] 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:31] 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:32] * timotimo puts a speshlog in front of him [14:33] 359 sp_guardconc [14:33] 42 sp_guardtype [14:33] 34 sp_guardrwconc [14:33] now if only i knew which one gets hit more often ... [14:36] now for some debugspam :) [14:37] hmmmm [14:37] 701148 guardrwconc b0rked [14:37] 1273 guardtype b0rked [14:37] 727 guardconc b0rked [14:37] it depends on how you want to do it [14:37] would you have guessed? [14:38] no, wouldn't [14:38] wait a minute [14:38] i actually want to build bridges for the least often taken paths [14:38] because every bridge i build moves unnecessary code out of the mainline [14:39] 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:41] 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 [14:41] hmmmmm [14:42] ok, i may be naive, but.... [14:42] 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 [14:43] 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? [14:45] yes, that's the first milestone in this project [14:45] i'm getting far ahead of myself [14:48] * brrt knows what that is like :-) [14:48] :D [14:49] 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 [14:50] 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 [14:50] 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? [14:52] hmmm [14:53] i don't really know, to be honest [14:54] right, i'd have to find the example again [15:05] i'm really not sure i want to be messing around with the deopt table :| [15:06] no.. i'm not suggesting that you should [15:06] in fact, i'm not suggesting anything [15:06] oh, is it enough to just add a little annotation? [15:06] i have no idea to be honest [15:07] in fact, i can just duplicate the annotation that's in front of the guard op? [15:12] 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 [15:13] and Deopt All apparently only appears before invoke_* ops [15:35] AFK for a bit [15:41] *** domidumont joined [16:12] 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 [16:17] oh crap [16:17] i'm adding branches to the *middle* of BBs [16:17] that sucks. [16:20] 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 [17:05] *** synopsebot6 joined [17:31] *** vendethiel joined [17:51] *** domidumont joined [17:51] 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 [17:53] hopefully nothing [17:53] if i make sure the linear order stays correct? [17:54] and inside the bridges we won't be throwing exceptions or anything [17:56] hmmm [17:56] that is .... okay, but very, very, very fragile [17:58] oh? [18:03] could you elaborate? [18:19] sorry, i'm somewhat busy [18:20] 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 [18:21] the alternative is that your forcedeopt gets a fixed number that ... for all i care, represents the original position of your guard [18:22] forever %) [18:22] that is just fixed by stealing the annotation [18:22] easy-peasy [18:22] because the annotation has the data in it, as far as i can tell [18:23] 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 [18:25] i only meant having the split put the two pieces a BB is split into in the original order [18:26] the bridge ought to go outside, of course. especially when we expect it to not be taken often [18:27] ah, alright [18:27] right, fully agree [18:29] so, no worries about fragility? or doing something "forever"? [18:38] *** domidumont joined [18:43] no, not really [18:43] in fact, the reverse [18:43] safe splitting of basic blocks is something we will probably need a lot of time [19:29] *** FROGGS joined [21:10] hm. vim over sshfs isn't working very well with all those modules i have, it seems like [21:11] *** Util joined [21:13] waiting multiple minutes to open this file ... ?!? [21:14] o_O [21:18] ...use ed? [21:19] nah, i'm using vim inside ssh now [21:23] ugh. idx. not fun :| [21:23] for splitting BBs, i mean. i'll have to come up with a new index [21:24] well, i can just go through linear_next and +1 the idxes [21:24] they aren't supposed to be stable anyway [21:24] ugh, initial_pc is supposed to just be the cached instruction pointer at the beginning [21:25] and it's an uint, so i can't just set it to -1 [21:26] i think i can just re-use the initial_pc from the original BB when i split [21:30] *** vendethiel joined [21:41] this is an ugly task [22:30] MoarVM: bdff4dc | timotimo++ | src/spesh/manipulate. (2 files): [22:30] MoarVM: Implement a BB-splitting manipulation function [22:30] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bdff4dc9e3 [22:30] ^- i bet it's b0rked beyond belief :) [22:46] 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 [22:50] MoarVM build failed. Timo Paulssen 'Implement a BB-splitting manipulation function' [22:50] https://travis-ci.org/MoarVM/MoarVM/builds/142899784 https://github.com/MoarVM/MoarVM/compare/8fc21d50aa4f...bdff4dc9e3a3 [22:50] *** travis-ci left [22:56] well, i should have at least tried to build it, seems like [22:58] MoarVM: f9dad06 | timotimo++ | src/spesh/manipulate. (2 files): [22:58] MoarVM: fix signature of split_BB_at [22:58] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f9dad06052 [23:24] *** travis-ci joined [23:24] MoarVM build passed. Timo Paulssen 'fix signature of split_BB_at' [23:24] https://travis-ci.org/MoarVM/MoarVM/builds/142905385 https://github.com/MoarVM/MoarVM/compare/bdff4dc9e3a3...f9dad06052ff [23:24] *** travis-ci left [23:25] good