GH-143732: SEND specialization#148963
Conversation
* SEND_VIRTUAL: for sends to virtual iterators e.g lists and tuples * SEND_ASYNC_GEN: for sends to async generators Tweak FOR_ITER_VIRTUAL so that SEND_VIRTUAL and FOR_ITER_VIRTUAL use equivalent guards
| "_PyStolenTuple_Free", | ||
| "PyObject_GC_UnTrack", | ||
| "_PyErr_ExceptionMatches", | ||
| "CALL_TP_ITERITEM", |
There was a problem hiding this comment.
I don't think this is right?
There was a problem hiding this comment.
It is correct in the normal build, but I'll need to exclude lists in the free-threading build.
There was a problem hiding this comment.
Special casing the free-threaded build is too messy, so I've removed this from the whitelist instead.
Fidget-Spinner
left a comment
There was a problem hiding this comment.
LGTM, just two questions, feel free to merge after addressing them.
| 0, /* am_anext */ | ||
| 0, /* am_send */ | ||
| .am_await = PyObject_SelfIter, | ||
| .am_send = _PyAsyncGenASend_Send, |
There was a problem hiding this comment.
Otherwise, the send needs to go through a call to the send method. I don't know why this wasn't implemented before.
| (PyLongObject *)PyStackRef_AsPyObjectBorrow(right)); \ | ||
| } | ||
|
|
||
| #define CALL_TP_ITERITEM(ITER, INDEX) \ |
There was a problem hiding this comment.
I know this is to make it non-escaping to the analyzer, but it would be clearer if you said CALL_TP_ITERITEM_NO_ESCAPE or something.
There was a problem hiding this comment.
I dropped the special meaning, to avoid problems with the free-threading build.
I'll just remove the macro, as it isn't doing anything useful any more.
I dropped it for the SAI. I'll update the name as you suggest for the JIT.
Documentation build overview
80 files changed ·
|
Adds 2 new specialized instructions:
SEND_VIRTUALfor sends to virtual iterators e.g lists and tuplesSEND_ASYNC_GENfor sends to async generatorsAlso, tweaks
FOR_ITER_VIRTUALso thatSEND_VIRTUALandFOR_ITER_VIRTUALuse equivalent guardsThis is aimed more at JIT coverage, especially ensuring that we can trace through
SENDinstructions, than interpreter performance.Performance is broadly neutral, but with improvements of 4-6% on the
async_generatorsbenchmark.