<masak> so, I just removed
https://github.com/rakudo/rakudo/blob/nom/src/vm/moar/Perl6/Ops.nqp#L460
locally; RT #124191 is still present afterwards :/
<synopsebot> Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=124191
<masak> so it's something deeper, then.
<dalek> rakudo/nom: ee7a375 | jnthn++ | src/vm/moar/Perl6/Ops.nqp:
<dalek> rakudo/nom: Remove dupe register free; masak++.
<dalek> rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ee7a3752d9
<masak> oh, jnthn++ beat me to it.
<masak> was still spectesting.
<masak> jnthn: RT #124191 is still at large, even after that remove.
<masak> jnthn: so there is *something* wrong with that code.
<jnthn> masak: That may fix *something*, but given the generated code works
before dynamic optimization kicks in, it's fairly clear we're looking for a
problem there.
<masak> jnthn: if you can't see it immediately, I'd recommend rolling back the
original commit that created that op.
<jnthn> masak: Nope, wrong approach.
<masak> if you say so.
<masak> we have a bug in the nom branch right now, and a way to make it go away
until we learn what's going on.
<jnthn> masak: It's pretty obvious from what we know that the commit in
question generates valid code.
<masak> jnthn: ah, so you're saying we should look at how it's
optimized/speshed instead?
<masak> I agree with that, I just don't see why we wouldn't remove the source
of the bug in the meantime. creating a more stable nom branch.
<jnthn> masak: Yes; presumably setting MVM_SPESH_DISABLE=1 makes it go away
* masak tries
<masak> jnthn: yes, setting MVM_SPESH_DISABLE=1 makes it go away.
<jnthn> masak: Right, so that narrows down where we're looking quite
significantly.
<masak> jnthn: not gonna argue with you about reverting the commit -- if you
prefer that it stay, it stays. but how do we find the optimize/spesh bug?
<jnthn> masak: Well, looking at the spesh log for one
<jnthn> masak: Though we might try disabling other bits to narrow it further
<masak> jnthn: I don't have the skills to do that at present. hoping that
someone else finds the tuits to do that.
<jnthn> masak: There's more env vars
<jnthn> masak: If you moar --help they're there
<jnthn> masak: Seems that they do help too...
<jnthn> masak: Setting MVM_SPESH_INLINE_DISABLE=1 also makes it go away
<jnthn> masak: Meaning that we can blame it on inlining busting...something.
<jnthn> masak: Further, you don't need a custom exception type for it
<masak> wow.
<masak> so I could've golfed it further?
<masak> fancy that :)
<jnthn> masak: Yeah, Exception.new
<masak> m: for ^207 { die Exception.new(); CATCH { default {} } }
<camelia> rakudo-moar d24f30: ( no output )
<masak> m: for ^208 { die Exception.new(); CATCH { default {} } }
<camelia> rakudo-moar d24f30: OUTPUT« in block at /tmp/ZLP2WH1C3n:1»
<masak> jnthn++
<jnthn> masak: I've a feeling it is a much more general issue.
* masak adds the conversation so far to the ticket
