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.
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.
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
nine for whatever reason, yes 18:21
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
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
[Coke] double checked, the t/02-rakudo/18-pseudostash.t failure on OS X on new-disp is not happening on master. 22:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!