(What's the DSL generator?)

(What's the DSL generator?)

Sorry I meant to write the DSL's abstract interpreter generator.

Latest performance result, pure uops, no JIT:
0-2% faster on Linux, 3% faster on macOS ARM64

It's possible that my comment in the PR about extensibility belongs here.

I'd like to explore an idea for simplifying the code generation a bit. See here for reference.

Currently, when we do constant evaluation for e.g. a binary add operation, we replace load A; load B; add with load A; load B; pop 2; load_const (A+B) and then peephole the load A; load B; pop 2 into oblivion.

(I'm writing load instead of any of LOAD_FAST or LOAD_CONST*, and pop for _SHRINK_STACK; load_const actually stands for _LOAD_CONST_INLINE or _LOAD_CONST_INLINE_BORROW.)

Looking at peephole_optimizations(), we only back over a few specific instructions: defined in op_is_zappable(), the set includes the "bookkeeping" instructions _SET_IP and _CHECK_VALIDITY, all flavors of _LOAD_CONST, and _LOAD_FAST. (But not _LOAD_CONST_CHECK, which is impure, i.e., it can fail, so we should never erase it.)

My first question is, when are we unable to optimize the _SHRINK_STACK instruction away? We know that this is only emitted as part of constant evaluation, which only happens when the arguments (of add, in the example) are all known constants.

I don't want to work out a formal proof, but I'm pretty sure that we can prove that the only way we can have a constant on the stack is if it was pushed by one of the following:

• a _LOAD_CONST* uop
• a _LOAD_FAST from a variable that is known to be a constant
• a pure operation (one of the type-specific unary or binary operator

Since the first two categories are considered zappable, they are fine. However, BINARY_OP_ADD_INT is not obviously zappable. Let's try to construct an example that might not get zapped: A + B*C, where A, B and C are known constants (either actual constants or _LOAD_FAST of a variable known to hold a constant, e.g. after x = 1). This generates the following unoptimized uops: load A; load B; load C; mul; add, and it gets then optimized to load A; load B; load C; pop 2; load_const (B*C); pop 2; load_const (A + B*C). If the peepholer were to look at the final pop 2 first, it would find it preceded by the initial pop 2, which is not zappable. However! The peepholer sees the initial pop 2 first. This one is preceded by two zappable loads (B and C), so the final pop 2 now finds itself preceded by load A; nop; nop; nop; load_const (B*C), and this should be zappable.

(Alas, it currently isn't, because is_zappable() omits _NOP from its list. This seems like a simple omission -- if I add it, nothing breaks.)

So what other things might intervene that make the sequence non-zappable? Well, there could be a non-constant LOAD_FAST followed by a POP_TOP in the middle. I can't think of what would cause that, but I don't want to rule it out either. Another example (using the walrus operator) is easier to imagine: A + (X := B*C) produces something like load A; load B; load C; mul; copy 1; store X; add. And while COPY is pure, it's not zappable, so we're stuck after peepholing with load A; load_const (B*C); copy 1; store X; pop 2; load_const (A + B*C).

That's too bad, because looking at that I can see that it ought to be simplifyable to load_const (B*C); store X; load_const(A + B*C) -- but I am okay with leaving that to a future optimization pass.

Hm, so all my idea boils down to is that we can probably move the _SHRINK_STACK peephole work to emit_const(), and the _CHECK_PEP_523 to a hand-written case in uop_abstract_interpret_single_inst(). Oh well.

(What I had hoped to arrive at was a proof that we will never need more output space than input space, and that we can do this on the fly so we won't need a separate output write buffer. But at least until the walrus example is solved, we can't.)

(What's the DSL generator?)

Sorry I meant to write the DSL's abstract interpreter generator.

Why would we not merge that? It seems to be an integral part of the PR.

(What's the DSL generator?)

Sorry I meant to write the DSL's abstract interpreter generator.

Why would we not merge that? It seems to be an integral part of the PR.

The alternative is Mark's version here https://github.com/faster-cpython/cpython/blob/8aad399240928a7dfe548c0154d7354c96a1f6ff/Python/tier2_specializer.c

I plan to eventually integrate something like that though.

The file you linked to would just be another input to the generator though. You'd still need a generator. All it saves you is about 150 lines in optimizer_analysis.c, at the cost of some more work in the generator. One possible advantage, because the new file is specific to the symbolic interpreter part, you could move the stack effect annotations there and possibly invent some annotations that are more suitable to that use case (but less proper when describing opcodes in general).