GH-125837: Rework the instructions for loading constants and returning values.

[markshannon]

Adds:

• RETURN_VALUE_FUNC
• RETURN_VALUE_GEN
• INSTRUMENTED_RETURN_VALUE_FUNC
• INSTRUMENTED_RETURN_VALUE_GEN
• LOAD_CONST_IMMORTAL

Removes:

• RETURN_VALUE
• RETURN_CONST
• INSTRUMENTED_RETURN_VALUE
• INSTRUMENTED_RETURN_CONST

• Issue: Refactor RETURN_VALUE and RETURN_CONST #125837

[markshannon]

Performance impact without the JIT is in the noise. Nominally 0.2% slower

Performance impact with the JIT is also in the noise. Nominally 0.2% faster.

Stats shows that almost 90% of LOAD_CONST are converted to LOAD_CONST_IMMORTAL. There is a 3% increase in EXTENDED_ARG due to LOAD_CONST RETURN_VALUE taking more space than RETURN_CONST.

My hypothesis is that the slowdown caused by extra dispatching is mostly offset by the more efficient LOAD_CONST in tier 1 and more streamlined RETURN_VALUEs.
In tier 2 there is no extra overhead for dispatching, which might be why we see a tiny speedup instead of a tiny slowdown.

[iritkatriel]

Is the only difference between RETURN_VALUE_FUNC and RETURN_VALUE_GEN the call to _PyEval_ClearThreadFrame vs _PyEval_ClearGenFrame? Couldn't _PyEval_FrameClearAndPop just switch on whether or not frame->owner == FRAME_OWNED_BY_GENERATOR?

[markshannon]

That's exact what it used to do.

We generally want to make decisions at compile time if we can.
It's the second bullet in #125837 (comment)

[iritkatriel]

We generally want to make decisions at compile time if we can.

We also made some efforts to reduce the number of bytecodes and the size of the eval loop implementation.
And copy-pasting 20 lines of code to change one is... controversial.

[markshannon]

And copy-pasting 20 lines of code to change one is... controversial.

It's 16 lines, but I see your point.

Doing this gives more flexibility to refactor and optimize the two return paths separately.
Both _PyEval_ClearGenFrame and _PyEval_ClearThreadFrame call _PyFrame_ClearExceptCode() but have to do
different things around that call.

For example, we could end up with something like this:

macro(RETURN_VALUE_FUNC) =  _CLEAR_FRAME + _POP_THREAD_FRAME + _RETURN_VALUE;
macro(RETURN_VALUE_GEN) = _GEN_POP_EXC_STATE + _CLEAR_FRAME + _RETURN_VALUE;

but not in this PR.

[iritkatriel]

Could you comment out rather than delete?

[markshannon]

I'd rather delete it, otherwise it just rots.

We do have version control, if you need it back.

[Eclips4]

Could you comment out rather than delete?

If it doesn't get deleted, compiler may raise warnings, see 325c5fe:
‘all_exits_have_lineno’ defined but not used [-Wunused-function]

[iritkatriel]

If it doesn't get deleted, compiler may raise warnings

But not if it's commented out.

[iritkatriel]

dis doc needs updating.

[bedevere-app]

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

[markshannon]

The magic comment is "I have made the requested changes; please review again".
I haven't, but I think I've justified my decisions.
@iritkatriel

[bedevere-app]

Thanks for making the requested changes!

@iritkatriel: please review the changes made to this pull request.

[iritkatriel]

I have reservation about introducing yet more code duplication, but I understand you are adamant this is a good idea.

[markshannon]

I'm closing this for now. We can revisit splitting up RETURN_VALUE when the full refactoring I suggested above is ready.

#125972 splits up LOAD_CONST and removes RETURN_CONST and shows slightly better performance.