Repository navigation
Don't inline slow path functions in the interpreter loop #132336
Description
Feature or enhancement
Proposal:
I was looking at the IPA inlining dump as part of investigating the root cause of gh-132295 and noticed that we're inlining a number of slow path functions related to specialization, instrumentation, and error handling in the interpreter loop when performing LTO (full list here):
_Py_Specialize_CallKw
_Py_Specialize_CompareOp
_Py_Specialize_ContainsOp
_Py_Specialize_ForIter
_Py_Specialize_LoadGlobal
_Py_Specialize_LoadSuperAttr
_Py_Specialize_Send
_Py_Specialize_StoreAttr
_Py_Specialize_StoreSubscr
_Py_Specialize_ToBool
_Py_Specialize_UnpackSequence
_Py_call_instrumentation
_Py_call_instrumentation_instruction
_Py_call_instrumentation_line
get_exception_handler
I suspect these are being inlined because we use unit tests for collecting PGO data. These should be executed relatively infrequently for "normal" Python code. We should mark them as noinline.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Activity
gh-132336: Mark a few "slow path" functions used by the interpreter l…
thesamesam commentedon Apr 10, 2025
The
coldattribute may be a fit here.Yhg1s commentedon Apr 10, 2025
As I understand it,
coldis ignored when using PGO, at least in GCC, so I don't think that would have the desired effect.thesamesam commentedon Apr 10, 2025
Ah, you're right:
markshannon commentedon Apr 11, 2025
What we do or do not want to inline depends on whether it is a tail-calling build or not.
For the tailcalling, many of the above function are on the hot path of the instruction they are part of.
For example,
get_exception_handleris only called in one place, it is on the hot/only path ofexception_unwind. Theinstrumentationfunctions in theINSTRUMENTEDinstruction, likewise.For the normal build, the size of
PyEval_EvalDefaultis the main concern and maybe we should be choosing functions based on size, as much as whether they are cold.Maybe using better profiles is the way to do this?
mpage commentedon Apr 11, 2025
This is a good point.
I think we should do both. For the non-tail-calling interpreter we should mark the specialization functions as noinline, since that's more reliable than trying to coax a black box into doing what we want. I also think we should continue marking the instrumentation and exception handling functions as noinline since we know that those should be rare / exceptional paths.
Revert pythongh-132336 noinline attributes on specializer/instrumenta…