gh-106581: Add 10 new opcodes by allowing assert(kwnames == NULL)

[gvanrossum]

Not all of these are useful, but I think they all work (I tried the same thing last week, when it crashed mysteriously; I've fixed so many crashes since then that I think it'll work now).

This leaves 14 17 CALL specializations that need to be split (or need gh-106603, allowing oparg and one cache entry per uop).

Some of the opcodes here surely need to be split into separate guards and actions; that can be done as needed.

• Issue: Call design for Tier 2 (uops) interpreter #106581

[gvanrossum]

So the test failure, in particular test.test_descr.ClassPropertiesAndMethods.test_keywords, shows that there's an unresolved problem. And of course it has to do with the kwnames variable. There's an instance of this in the Tier 1 interpreter and another in the Tier 2 interpreter. But what happens if a Tier 2 instruction that uses kwnames deoptimizes? The corresponding Tier 1 instruction will find kwnames == NULL since there is no room in the API to pass the kwnames back from Tier 2 to Tier 1.

Looks like this will have to wait until gh-105848, where it is proposed that the kwnames gets pushed on the stack instead of being a local variable in the eval loop.

A fair number of these instructions don't really use kwnames, they just contain an assert(kwnames == NULL) statement. I think I'll play around with a way to allow this assertion but not other uses of kwnames.

[gvanrossum]

Most test failures are expected (for a run with -Xuops on by default). But the test_list failure pointed to a recent bug in the Tier 2 interpreter (not interpreted here). Fixing in gh-106756.

[gvanrossum]

PS. I have a benchmark running on this with -Xuops enabled by default. That should give us an idea of how much slower the Tier 2 interpreter is.

[gvanrossum]

The benchmark (using uops wherever we can) comes in 4% slower than main. That's good to know.

[gvanrossum]

@markshannon What do you think of this?