Tier 2 cleanups and tweaks

[gvanrossum]

• Rename _testinternalcapi.get_{uop,counter}_optimizer to new_*_optimizer
• Use _PyUOpName() instead of _PyOpcode_uop_name[]
• Add target to executor iterator items -- list(ex) now returns (opcode, oparg, target, operand) quadruples
• Add executor methods get_opcode() and get_oparg() to get vmdata.opcode, vmdata.oparg
• Define a helper for printing uops, and unify various places where they are printed
• Add a hack to summarize_stats.py to fix legacy uop names (e.g. POP_TOP -> _POP_TOP)

[mdboom]

Regarding _PyUOpName, specialize.c has something different. I guess the names < 256 are shared with the Tier 1 instructions, but I don't know the history there. Maybe we use _PyUOpName here, too?

for (int i = 0; i < 512; i++) {
        if (i < 256) {
            names = _PyOpcode_OpName;
        } else {
            names = _PyOpcode_uop_name;
        }
        if (stats->opcode[i].execution_count) {
            fprintf(out, "uops[%s].execution_count : %" PRIu64 "\n", names[i], stats->opcode[i].execution_count);
        }
        if (stats->opcode[i].miss) {
            fprintf(out, "uops[%s].specialization.miss : %" PRIu64 "\n", names[i], stats->opcode[i].miss);
        }
    }

[gvanrossum]

Regarding _PyUOpName, specialize.c has something different. I guess the names < 256 are shared with the Tier 1 instructions, but I don't know the history there. Maybe we use _PyUOpName here, too?

I saw that, and didn't immediately know how to rewrite that. Looking again I now know what to do (I had misunderstood what that code does) and I will fix this.

[gvanrossum]

I saw that, and didn't immediately know how to rewrite that. Looking again I now know what to do (I had misunderstood what that code does) and I will fix this.

Fixed. There's one change: when an uop is also a Tier-1 op, the previous version would print the Tier-1 name (without a leading underscore). The new version always prints the Tier-2 name. E.g.

> uops[POP_TOP].execution_count : 83
---
> uops[_POP_TOP].execution_count : 83

I believe the latter is more correct.

[mdboom]

I believe the latter is more correct.

Yeah, it probably is. This will make the stats before and after this change no longer comparable. That's probably fine -- if we find ourselves needing to do that the update to summarize_stats.py should be straightforward.

[gvanrossum]

This will make the stats before and after this change no longer comparable. That's probably fine -- if we find ourselves needing to do that the update to summarize_stats.py should be straightforward.

Oh, that's unfortunate. Didn't we just recently have a big stir about unexplained stats changes?

Regarding a possible fix, were you thinking of just changing uops[POP_TOP].execution_count into uops[_POP_TOP].execution_count (etc.) in load_raw_data(), just before the line stats[key.strip()] += int(value)? I'm tempted to do that.

[gvanrossum]

I foresee some merge conflicts with gh-114142. I'd rather see that merged first.

[mdboom]

Regarding a possible fix, were you thinking of just changing uops[POP_TOP].execution_count into uops[_POP_TOP].execution_count (etc.) in load_raw_data(), just before the line stats[key.strip()] += int(value)? I'm tempted to do that.

Yes, exactly. Just something to normalize all the uops to have a _ prefix if the data doesn't already have it.

[Fidget-Spinner]

Small merge conflict with #115550.

[gvanrossum]

@markshannon Could you review this? I intend to merge after your side exits PR lands.

[markshannon]

One suggestion, otherwise LGTM