Break calls into two or three bytecodes for better specialization.

[markshannon]

We already do this partly with the PRECALL_METHOD instruction which is inserted before the CALL_[NO_]KW to setup the correct argument offsets.

I propose adding a PRECALL_FUNCTION instruction to be inserted for the non-method case.
This would, in the non-specialized case, setup argument offsets for a non-method call.

The motivation for this change is to split the specialization of calls into two parts.
Currently we have a sort of N*M problem with specializing calls. We want to specialize for both the type of callable (builtin-function, Python function, bound-method, builtin-class, Python class) and for the argument handling (simple arguments, *args, **kwargs, defaults, etc.)

By splitting the call sequence into two we need N+M specializations instead. Since N is at least 5 and M is at least 3, this saves a lot of duplication. Instructions specialized for both type and shape are larger than specializations for just one, so we end up with (N*M*2) vs. (N+M).

The obvious downside of this is the increased memory use for code objects. The extra 2 bytes for the PRECALL_FUNCTION is not an issue, although the additional location information may be. The extra 8 or 16 bytes for the cache is significant, but should be tolerable.

[markshannon]

As a motivating example, consider calls to a normal Python class (by "normal" I mean one that inherits from object and does not override __new__)

My initial attempt to do this is both complex and broken, see python/cpython#30415
It could be made to work with additional checks, but there is a lot of redundancy there.

By splitting the CALL_NO_KW into PRECALL_FUNCTION; CALL_NO_KW we can specialize PRECALL_FUNCTION to do the setup work of creating the object and pushing the cleanup frame without worrying about how to specialize the call to __init__.

Likewise, CALL_NO_KW won't need to be specialized for classes or bound-methods as it will only ever see Python functions (once PRECALL_FUNCTION has been specialized).

[markshannon]

Attempting to implement the above scheme, it seems like breaking the _KW forms into three bytecodes is the way to go.

f(x, name=y) would become PRECALL_FUNCTION 2; KW_NAMES n; CALL where n is the index in the const array of the keyword name tuple, ("name",).
Having only one CALL instruction (ignoring the slow CALL_FUNCTION_EX for now) would make the code simpler and make it easier to apply specializations of CALL to multiple kinds of calls.

The main benefit of merging CALL_NO_KW and CALL_KW is that we don't need two specializations for anything using vector-calls.
If the specializer needs to differentiate it can do so easily by checking if the previous instruction was KW_NAMES.

Internally the interpreter would have several variables (probably in a struct) to describe the "shape" of the call.

To outline how this would work, take the example f(x,name=y):

PRECALL_FUNCTION 2 would set the callable to f and set positional_args to 2 and kwnames to NULL.
KW_NAME n would set kwnames to point to ("name",) and reduce positional_args to 1.
CALL would then make the call, as CALL_KW does now.

Cost of adding KW_NAMES

The additional cost of the KW_NAMES instruction should be negligible.

Without KW_NAMES, f(name=x) compiles to:

LOAD_GLOBAL f
LOAD_FAST x
LOAD_CONST (name,)
PRECALL_FUNCTION
CALL_KW 1

With KW_NAMES, f(name=x) compiles to:

LOAD_GLOBAL f
LOAD_FAST x
PRECALL_FUNCTION
KW_NAMES index of  (name,)
CALL 1

Which is the same number of dispatches, and saves a pop, INCREF and XDECREF. It does mean that
PRECALL_FUNCTION needs to set kwnames to NULL, but overall it should cost nothing.

[markshannon]

A bit more detail:

There will be two PRECALL instructions; PRECALL_FUNCTION for most calls, and PRECALL_METHOD to be paired with LOAD_METHOD. The operand for both will be the total number of arguments (both positional and named).
The KW_NAMES instruction will take the index into the constants array as its operand.
The final instruction in the sequence, CALL will take the number of named arguments as its operand. This is redundant information, but we unconditionally load the operand, so we might as well use it.

For example f(x, name=y) will compile to:

LOAD_GLOBAL f
LOAD_FAST x
LOAD_FAST y
PRECALL_FUNCTION 2
KW_NAMES N # N is the index of (name,) in the consts array.
CALL 1

and g(x) will compile to:

LOAD_GLOBAL g
LOAD_FAST x
PRECALL_FUNCTION 1
CALL 0

[ericsnowcurrently]

This is redundant information, but we unconditionally load the operand, so we might as well use it.

Would it be problematic to change the meaning of the oparg in the future if we find some other use for it? It sounds like not.

[markshannon]

bpo issue: https://bugs.python.org/issue46329

[markshannon]

python/cpython#30855