|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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): gist.github.com/niner/0fa1f36ea49a...8b9e5f722c | 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
|
|||