bpo-46841: Move the cache for LOAD_GLOBAL inline.

[markshannon]

Also removes duplication of the _PyOpcode_InlineCacheEntries table.

https://bugs.python.org/issue46841

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @markshannon for commit 26d0d70 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

[markshannon]

Performance is underwhelming.
Not surprising, given that we are duplicating the cache and still having to handle the old caches.

What is notable is that the number of EXTENDED_ARG instructions more than doubles from ~0.3% to ~0.7%.

[brandtbucher]

Performance is underwhelming.
Not surprising, given that we are duplicating the cache and still having to handle the old caches.

Yeah, I suspect we may not see a ton of payoff until we convert most/all of the caches.

[brandtbucher]

A few things:

• The magic number needs to be bumped every time we do this.
• I thought we decided to use _Py_CODEUNIT everywhere you're using uint16_t now (it may also be worth adding _Py_TWOCODEUNITS and _Py_FOURCODEUNITS aliases for uint32_t and uintptr_t, respectively).

[bedevere-bot]

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

[markshannon]

A few things:

* The magic number needs to be bumped every time we do this.

👍

* I thought we decided to use `_Py_CODEUNIT` everywhere you're using `uint16_t` now (it may also be worth adding `_Py_TWOCODEUNITS` and `_Py_FOURCODEUNITS` aliases for `uint32_t` and `uintptr_t`, respectively).

Hmm, I'd prefer not. Versions, for example, are 32 bit value, not 2 code units. If the size of the _Py_CODEUNIT were to change, we would still want versions to be 32 bit numbers.
So, the structs should be defined in terms of code units, but the read/write helpers should be in terms of width.

Maybe we should give up on the pretense that the size of the code unit can be easily changed, and replace _Py_CODEUNIT with the standard type uint16_t?

[brandtbucher]

Hm, looks like the magic number wasn't actually changed... bad merge?

[markshannon]

I figured we didn't need more than one version number per day.

[markshannon]

#31618 has another version number bump.

[brandtbucher]

Ah, I see what you did now. Thanks for clarifying.