-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to handle YIELD_VALUE in Tier 2 #628
Comments
According to the stats:
So 63% of I expect that Given that, It is |
Okay, I'll educate myself about |
I am still stuck on this. E.g. how can we identify the code object of the generator while tracing through a for-loop starting with Meanwhile, it looks like
|
A few possible options exist:
There are other complications though.
Another random idea:
Mark and I are hoping to dive more deeply into this at the sprint in Brno. |
This is still very tricky; we decided that we have other priorities, e.g. trace stitching, for which we first need to merge the Tier 2 interpreter into the Tier 1 interpreter (#631). |
The basic problem is that we don't have the runtime information necessary to project the trace until we execute the code. The idea is that we exit the trace with a special micro-op that resumes optimization, passing in the actual value seen at runtime. It is conceptually a bit complex, but not that hard to implement. This approach also works for calls and returns, so we could throw out the function cache, which doesn't work well for closures anyway. |
YIELD_VALUE is currently the most-executed Tier 1 instruction that doesn't have a translation into Tier 2 uops.
But how should we handle it?
yield
is highly asymmetric -- the generator's frame is entered (resumed) by calling__next__()
,send()
orthrow()
, but it is left through theYIELD_VALUE
bytecode. We don't specialize any of those calls, so we can't really do something similar to_PUSH_FRAME
on the call (yet -- if we can specializelist.append
presumably we can specializegenerator.__next__
).It might be possible to trace through
YIELD_VALUE
in a way similar to_POP_FRAME
, if we know we'll always yield to the same frame, and if we know the code running in that frame. This would only make sense if we also traced through__next__()
orsend()
though, otherwise we'd quickly run out of frames.Concluding, I don't see what to do for
YIELD_VALUE
in Tier 2. Am I missing something, @markshannon or @brandtbucher?The text was updated successfully, but these errors were encountered: