Description
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()
or throw()
, but it is left through the YIELD_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 specialize list.append
presumably we can specialize generator.__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__()
or send()
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?