| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:46 squashable6 left 00:47 squashable6 joined 03:45 leont left 10:59 lizmat left 11:01 lizmat joined 11:55 squashable6 left 11:56 squashable6 joined 12:19 leont joined 13:05 patrickb joined
nine jnthn: disregard that bit about there being only one assigning node. I looked at the wrong register there. It does see both assigning nodes. But for phi creation it only considers the write after the throwy instruction. The phi node has 2 preds: the end of the handler area and the takehandlerresult node. 13:10
jnthn: at the end of the handler area the stack top for the register is the write after the throwy instruction. From the perspective of the takehandlerresult node the register's stack is even empty as we went straight from the entry node to the takehandlerresult node. 13:11
jnthn: We simply do not consider the control flow from the entry node (0) to the the initializer node (1) on to the throwy node (via 2, 3 and 4 to 5) and from there back to the entry node (0), takehandlerresult (8) and then to the phi (9): 13:15
MasterDuke nine: is this the sort of thing where a fix is going to end up closing a whole lot of seemingly unrelated issues? 13:51
14:11 lizmat left 14:12 lizmat joined
nine MasterDuke: well if I'm right then...yes, maybe? After all this definitely leads to a segfault due to a NULL coming out of a decont. I guess that's about as arbitrary as it gets :) 14:16
Funny: it's Sunday, I'm actually on vacation for a week and still I'm at the office for the first time in several weeks - to water my plants and dust off my speakers ;) 14:17
14:25 jpf1 left, jpf1 joined 14:59 sxmx left 15:13 sxmx joined 16:19 greppable6 left, shareable6 left, sourceable6 left, releasable6 left, bisectable6 left, bloatable6 left, unicodable6 left, benchable6 left, statisfiable6 left, coverable6 left, tellable6 left, evalable6 left, quotable6 left, committable6 left, notable6 left, nativecallable6 left, squashable6 left, linkable6 left 16:20 squashable6 joined, benchable6 joined, linkable6 joined, nativecallable6 joined, releasable6 joined, notable6 joined 16:21 bloatable6 joined, shareable6 joined, committable6 joined, quotable6 joined, bisectable6 joined, unicodable6 joined, tellable6 joined, sourceable6 joined, statisfiable6 joined 16:22 greppable6 joined, coverable6 joined, evalable6 joined 17:00 cog_ left 17:13 cog joined 17:15 domidumont joined 17:27 Kaeipi left 18:00 sena_kun left 18:07 sena_kun joined 18:32 domidumont left 18:46 zakharyas joined 18:47 Kaiepi joined 19:07 sena_kun left 19:08 sena_kun joined
nine MasterDuke: actually that's the reason why I'm so interested in this issue. We know that there are random seeming segfaults and this is the only bug we know about that could single handedly explain those 19:20
MasterDuke good point. and it took a random turn of events to even bring this to light 19:21
random example of oddly slow rakudo code (there's still a bug in rakudo around this example), i see the oddly high number of deopts, go down the path of enabling removing of optimizations, eventually do so, example isn't any faster and doesn't have any fewer deopts, figure out it's also a spesh stats problem with decont, change stat logging in 19:26
decont, get a segfault that shouldn't happen, work around the segfault, you investigate the actual source cause of the segfault...
20:28 lizmat left 20:30 lizmat joined 20:47 patrickb left 21:42 zakharyas left 23:07 dogbert11 joined 23:10 dogbert17 left