Rework how captured values are written to GeneratorBailInInstrs #6293
Conversation
zenparsing
force-pushed
the
bailin-captured-values
branch
3 times, most recently
from
fb8c3b2
to
a0cdafa
Compare
|
So there was a legitimate problem, not just an over zealous failfast? Good to see it fixed. |
|
@MikeHolman would you mind taking a look at this PR for me? This bug is getting in the way of the other generator-related work that I'm doing. |
lib/Backend/IR.cpp
Outdated
| } | ||
|
|
||
| Assert(instr->m_next && instr->m_next->m_next); | ||
| return instr->m_next->m_next->AsGeneratorBailInInstr(); |
There was a problem hiding this comment.
I feel like this is asking for trouble, maybe we want to guard this with AssertOrFailFast(IsGeneratorBailInInstr()), or even just do an early return if it isn't
There was a problem hiding this comment.
Yeah, I agree the m_next->m_next thing is icky. What would be a better way?
Clearly every OpCode::Yield must have a following GeneratorBailIn right? So it's just a matter of where in the forward list it is. If there's isn't one in the forward list (before the next Yield) then we have to fail fast.
So we could do this:
for (auto* next = instr->m_next; next; next = next->m_instr)
{
if (next->m_opcode === Js::OpCode::Yield)
break;
else if (next->IsGeneratorBailInInstr())
return next->AsGeneratorBailInInstr();
}
AssertOrFailFastMsg(false, "Yield not followed by GeneratorBailInInstr");Do you think that would be better?
There was a problem hiding this comment.
I think you could alternatively hit a return instead of another yield - so maybe break to the failfast for a return or a yield?
zenparsing
force-pushed
the
bailin-captured-values
branch
from
a0cdafa
to
8a4ff27
Compare
…eneratorBailInInstrs Merge pull request #6293 from zenparsing:bailin-captured-values This PR fixes an existing bug in the generator JIT implementation found by @rhuanjl. In order to generate bail-in code, the backward pass copies "captured value" information from a yield's `BailOutInfo` into the associated `GeneratorBailInInstr`. The current implementation was copying `bailOutInfo->capturedValues->constantValues` on every pass over the yield instr. However, in a loop the yield instr is passed over twice, and each time entries are moved from `bailOutInfo->capturedValues` into `bailOutInfo->usedCapturedValues`. On the second pass over the instr, the current implementation is overwriting the constant values list with an empty list. With this change, the constant values are transferred to the bailin instr directly in the code that processes bailout constant values and copy prop syms.
This PR fixes an existing bug in the generator JIT implementation found by @rhuanjl.
In order to generate bail-in code, the backward pass copies "captured value" information from a yield's
BailOutInfointo the associatedGeneratorBailInInstr. The current implementation was copyingbailOutInfo->capturedValues->constantValueson every pass over the yield instr. However, in a loop the yield instr is passed over twice, and each time entries are moved frombailOutInfo->capturedValuesintobailOutInfo->usedCapturedValues. On the second pass over the instr, the current implementation is overwriting the constant values list with an empty list.With this change, the constant values are transferred to the bailin instr directly in the code that processes bailout constant values and copy prop syms.