Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:59 greppable6 left, coverable6 left, bloatable6 left, evalable6 left, bisectable6 left, tellable6 left, unicodable6 left, committable6 left, releasable6 left, statisfiable6 left, notable6 left, sourceable6 left, shareable6 left, quotable6 left, linkable6 left, benchable6 left, squashable6 left 01:00 coverable6 joined, unicodable6 joined 01:01 squashable6 joined, bisectable6 joined 01:02 committable6 joined, evalable6 joined, linkable6 joined, benchable6 joined 01:04 frost left 01:34 frost joined 02:01 frost left 02:18 notable6 joined 02:38 nativecallable6 joined 03:19 tellable6 joined 03:50 bloatable6 joined 04:04 greppable6 joined 04:16 squashable6 left 05:17 shareable6 joined 05:50 releasable6 joined 06:04 reportable6 joined 08:12 Kaiepi left 08:20 Kaiepi joined 08:26 Kaiepi left 08:39 Kaiepi joined, frost joined 09:04 statisfiable6 joined 09:43 sourceable6 joined 09:44 frost left 09:46 frost joined 09:50 frost left 12:02 reportable6 left 12:05 reportable6 joined
nine So, the "Label lost with spesh enabled (#4456)" seems to be connected to PHI elimination during facts discovery. 15:39
I could track it down to Spesh of 'push-all' (cuid: 2075, file: SETTING::src/core.c/Any-iterable-methods.pm6:365) and specifically to r10. This register only has dead writers, but if we eliminate them, we run into the "labeled next without loop construct" error. 15:40
That register is never read (except by 2 PHI nodes) and only written by the initial null instruction and then in "set r10(4), r9(6)" 15:41
Now r9(6) contains the result of "getattr_o r9(6), r8(12), r5(12), lits($!label), liti16(2)" 15:42
MasterDuke similar/related to the incorrect ssa bug you fixed a little while ago? 15:45
nine No, in this case it looks like that code is really dead. But apparently it does have some side effect that's needed. Or that's covering up the real issue 15:59
This is the spesh log in question: gist.github.com/niner/4138c5a635a1...f407c72346 16:00
The difference between Before and After is only a couple of missing null instructions in BB 1 and removal of lines 324, 356 and 376. 16:01
And it's definitely not the null instructions. I've shrunk down the diff to just the 3 mentioned lines and it still explodes. 16:06
At least it doesn't look completely arbitrary. We've got an error message about a label and a register that's connected to $!label.
16:28 quotable6 joined
MasterDuke are we sure it's spesh? what about disabling spesh but enabling some of the other stressors? 17:11
nine Yes. I'm now certain it's that set instruction. Without it we get the error message 17:37
MasterDuke so a write that's theoretically unnecessary is actually necessary? 17:45
18:02 reportable6 left
nine for whatever reason, yes 18:21
18:41 discord-raku-bot left 18:42 discord-raku-bot joined
timo doesn't happen to haev to do with our partial escape analysis? 19:05
i'm not sure if very mmuch about that shows up in the spesh log
19:10 discord-raku-bot left 19:11 discord-raku-bot joined
nine Happens with MVM_SPESH_OSR_DISABLE=1 MVM_SPESH_PEA_DISABLE=1 MVM_JIT_DISABLE=1 MVM_SPESH_INLINE_DISABLE=1 and practically all spesh optimizations disabled. 19:14
So really, all spesh is still doing is remove that set instruction and 2 PHIs
timo have you tried throwing out phi elemination? they aren't instructions that actually show up in the output, after all 19:18
nine I have. Throwing out the PHIs is not the problem. We really need that Label in that register 19:22
We need it because it would be used by the handler. Currently trying to find the mechanism for such handlers and where they are expecting things in the code. 19:23
Looks to me like we're really just missing a usage relationship from the handler to this register. 19:24
MasterDuke aren't the handlers catches for control exceptions? 19:26
nine they are
And MVMFrameHandler has a label_reg field which I bet is pointing at our "optimized away" register. 19:27
But in all of spesh, nothing cares about such a field
While e.g. there's also a block_reg and that is checked for in is_handler_reg 19:28
MasterDuke i assume you've tried to catch it in rr and look for writes/reads to a label_reg? 19:30
src/spesh/inline.c:942 looks like a write to it 19:31
nine Got it :) 19:42
MasterDuke nice
Geth MoarVM/fix_spesh_losing_label_reg: 0ee995e3b9 | (Stefan Seifert)++ | 2 files
Fix spesh optimizing away still needed label register

Objects representing loop labels are kept in a register and may be used by loop handlers (like next LABEL). Spesh did not take this relationship into account, just saw a register that was written to, but not otherwise used and optimized the writers of this register away. Fix by giving a handler's label_reg the same treatment as block_reg.		 19:51
MoarVM/fix_spesh_losing_label_reg: a932b1732c | (Stefan Seifert)++ | 2 files
Fix spesh optimizing away still needed label register

Objects representing loop labels are kept in a register and may be used by loop handlers (like next LABEL). Spesh did not take this relationship into account, just saw a register that was written to, but not otherwise used and optimized the writers of this register away. Fix by giving a handler's label_reg the same treatment as block_reg.
Fixes Rakudo issue #4456		 19:52
nine And PR github.com/MoarVM/MoarVM/pull/1522
So....CodeFactor tells me that spesh contains complex code. How observant. It also claims that this is something new and I introduced it :D 19:54
MasterDuke nice fix 19:55
Nicholas I *think* that at times it has told me that there are new "issues" or resolved "issues" in functions I didn't even touch
nine same this time
timo nine: you already investigated and fixed a case where spesh bytecode generation at the end throws an assertion about deopt indices or something? 19:58
MasterDuke maybe one of the moarvm github admins can look at the settings and see if we can make it only warn, not turn a pr red 20:00
nine timo: doesn't ring a bell 20:01
timo oh, ok 20:02
nine Maybe this one? github.com/MoarVM/MoarVM/commit/79...95ddbf9af4 20:03
timo rebasing the "compile disp programs" branch on latest new-disp somehow got sp_assertparamcheck to disappear and i don't see it in the diffs any more
hmm
vrurg I have a terminology question. If I say that bytecode is grouped into frames – how much incorrect would it be? Trying to formulate how inner blocks are actually getting invoked. 20:31
timo one frame has one blob of "original" bytecode, though in moarvm's code we differentiate between static frame and frame, where the frame is one incarnation of a frame, like you'd have on a call stack 21:09
and of course there's more than just the original bytecode for frames
21:13 evalable6 left, linkable6 left 21:14 linkable6 joined 21:15 evalable6 joined 21:16 reportable6 joined
[Coke] double checked, the t/02-rakudo/18-pseudostash.t failure on OS X on new-disp is not happening on master. 22:43
23:38 linkable6 left, evalable6 left 23:39 evalable6 joined 23:40 linkable6 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!