I propose to move functions to call objects into a new Objects/call.c file.

It should easy maintainance since all moved functions are inter-dependent: it becomes easier to keep them consistent since they are in the same fle.

I also have a small "hope" that moving "call" functions in the same file should help the compiler to produce more efficient code and that we will get a better "code placement". Closer functions should enhance the usage of the CPU instruction cache.

I don't know exactly how to measure the effect of code placement. My plan is to push the change, and then watch speed.python.org timeline.

Attached call.patch:

* Add Objects/call.c file
* Move all functions to call objects in a new Objects/call.c file.
* Rename fast_function() to _PyFunction_FastCallKeywords(). 
* Copy null_error() from Objects/abstract.c
* Inline type_error() in call.c to not have to copy it, it was only called once.
* Export _PyEval_EvalCodeWithName() since it is now called from call.c.


The change comes from the issue #29465. Copy of my msg287257 from this issue:
---
Serhiy Storchaka added the comment:
> Isn't the Python directory more appropriate place for call.c?

I moved code from other .c files in Objects/, so for me it seems more
natural to add the code in Objects/ as well. It seems like most of the
code in Python/ is not "aware" of types defined in Objects/. But I
don't have a strong opinion on the right directory.

Objects/call.c is 1500 lines long. IMHO the code became big enough to
justify to move it to a new file ;-)
---


Once we have a call.c file, we may try other changes to enhance the code placement:

* Add "#define PY_LOCAL_AGGRESSIVE" (only used by Visual Studio)
* Tag functions with _Py_HOT_FUNCTION: see the issue #28618 for discussion on __attribute__((hot)). The last time I checked, it wasn't enough to fix all "code placement issues".
* Reorder functions in call.c: I dislike this idea, IMHO it's too hard to guess ourself what is the best order, and it's likely to produce many commits for little benefit

See also the issue #29465: "Add _PyObject_FastCall() to reduce stack consumption.