nine Why does the MAST compiler define its own constants for MVM_EX_ACTION_*? 15:04
Another interesting bit: _disabling_ the JIT and removing the goto at the end of the inline causes segfaults - with a completely screwed up stack. 15:29
And when the non-JITed version doesn't segfault, it throws the infamous "const_iX NYI" error. So something really must corrupt some memory. 15:30
timotimo i wonder if it's worth the hassle to introduce read-only sections to put the bytecode into? 15:36
nine Still not really closer to answering the question of what frame handlers have to do with INLINE_START and INLINE_END annotations. 15:42
timotimo well, that changes where we look, right?
nine What do you mean? 15:43
timotimo well, we sometimes want to throw something "from" an outer frame
nine It breaks when the handler's GOTO annotation is outside [INLINE_START..INLINE_END]. 15:45
What really confuses me is that there's almost nothing that even uses INLINE_END information. 15:47
timotimo but it changes the ranges in the handler table
and those probably impact lots of places? 15:48
nine But that's why it makes no sense: the ranges in the handler table are defined by the FH_START and FH_END annotations, not INLINE_START, INLINE_END
timotimo huh, but we're supposed to store the inline start and end, too? 15:50
nine But maybe the whole INLINE_END thing is just a red herring. Moving INLINE_END "fixes" things only when the JIT is enabled. The weird segfault when the JIT is disabled is unaffected. 15:53
timotimo hmm 15:54
i'm sufficiently distracted such that i can't think about this 16:05
nine The only thing that would make some sense would be that it's some deopt issue. But I can't find any indication that the optimized cuid is deoptimized somewhere 16:10
Can find neither the inliner, nor the inlinee's cuid in the deopt log 16:16
timotimo hm, OK :\
jnthn INLINE_END is used to src/spesh/codegen.c and a couple of places under src/jit/. It's used at code-gen time to build the table of deopt extents 16:18
Bytecode extents for when we interpret spesh'd code, and machine code extents for JIT
It's used to figure out "are we in an inline" during deopt, but also when resolving $*FOO 16:19
nine jnthn: order in the deopt table does not matter, does it? 16:31
jnthn: also can you confirm that the comment in src/spesh/deopt.c:118 just does not make sense? We get that offset from the inlines and deopt tables, not from any instruction. 16:33
jnthn iirc, order does matter in so far as innermost inlines should come first 17:52
nine: And yeah, that comment seems out of date 17:54
nine jnthn: the way it works now (in master and my branch) the innermost inlines will always be last. The inlinee's deopt table is appended to the inliner's 18:19
jnthn nine: Hm, I wonder if we scan it in reverse order then...can't remember 18:42
Ohh...
Maybe we don't scan it at all in deopt
'cus we pass in the deopt index
Or some such
I forget
(Sorry, mostly afk today)
Somewhere, we must be figuring out the "chain" of inlines, however, so we can reassemble the call stack
nine jnthn: uninline in deopt.c just iterates over cand->inlines and creates the frames. And there I'm quite sure we want to work from outer to innermost frame. 18:47
jnthn Oh, I guess I coulda done it that way too 18:49
nine So no smoking gun there...
jnthn Either way there's inter-loop fixups
Could always try turning on the deopt logging flag and comparing wiht master 18:50
iirc it outputs what frames it recreated
dinner, bbl 18:52
nine jnthn: I have 2 test cases where I used MVM_SPESH_LIMIT to find the optimization that breaks the code. In one case there is no deoptimization at all of the affected frame and in the other case there are no recreated frames (which I take as we weren't in inlined code at the time) 18:58
Ok, now it gets really interesting. 19:02
I compared the deopt log of both test cases with that on master. In both cases the log is identical (modulo offset/target differences of course) _except_ for one extra "Recreated frame" message on master. 19:04
The message is about the inlinee of the breaking optimization but NOT the same inliner. 19:05
timotimo that sounds fun, but maybe we're just(?) doing better at inlining in your branch for some reason?
nine And in both cases it's a deopt all that causes the frame to be created on master but not on inline_in_place 19:10
nine Correction: the missing "Recreated frame" message is exactly about the inlinee in the inliner of the breaking optimization 21:15
I just misread the deopt log before
samcv github.com/MoarVM/moarvm.org/pull/10 21:18
this looks fine i think?
lizmat yeah, looks ok to me 21:26
nine jnthn: github.com/MoarVM/MoarVM/blob/mast...eopt.c#L32 are you sure it's supposed to be offset < cand->inlines[i].end? Shouldn't that be <=? 21:28
lizmat
.oO( those pesky off-by-ones )
 21:48
nine In fact, I'm pretty sure it should be <= as .end is the offset of the last instruction in the inlined code. And the spectest shows that it can at least not be much wronger ;) 21:51
Geth MoarVM: 7ea08024ed | (Stefan Seifert)++ | src/spesh/deopt.c
Fix off-by-one error in uninline

The INLINE_END annotation sits on the last instruction of a chain of inlined basic blocks, so it's this instruction's offset in the bytecode we record as the end of the inlined code (mirroring the start offset). This means that if we are exactly at cand->inlines[i].end, we are still in inlined code and have to re-create the frame on uninlining.
This probably didn't cause issues before because inlined code always ends with a goto.

Powered by Cro and the Raku® Programming Language.

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

Thank you!