Nit comment:

Even if the explanation about type is described at https://github.com/Fidget-Spinner/cpython_optimization_notes/blob/main/3.13/uops_optimizer.md,

But are you going to write a simple explanation about what is pure, mandatory and guard in somewhere of the CPython repository?

Yep I definitely will. Probably at the top of the bytecodes.c file or the interpreter definition documentation.

The mandatory annotation makes no sense to me.

The example and explanation I gave is ill-defined. The more correct definition of mandatory is that it cannot be const evaluated or type prop eliminated. An example is _CHECK_STACK_SPACE. This guard is only known at runtime, not compile-time. This just tells the abstract interpreter generator not to attempt to const/type-evaluate it.

guard makes more sense, but it needs to be precisely defined before we add it.

guard is a misnomer I think, I will likely rename it to passthrough. Basically for correctness' sake, the abstract interpreter invalidates all mutable type information gained at the boundaries between pure and impure instructions. The reasoning is that the impure instruction could have modified it. E.g.

a.attr
b()
# Can't use the same type information here. Needs to guard again.
a.attr

However, for passthrough instructions, this won't happen.

The mandatory annotation makes no sense to me.

The example and explanation I gave is ill-defined. The more correct definition of mandatory is that it cannot be const evaluated or type prop eliminated. An example is _CHECK_STACK_SPACE. This guard is only known at runtime, not compile-time. This just tells the abstract interpreter generator not to attempt to const/type-evaluate it.

Nothing is known initially when optimizing, but any instruction can potentially become redundant as more is known about the state of the program. _CHECK_STACK_SPACE can be eliminated:

_CHECK_STACK_SPACE 20; _CHECK_STACK_SPACE 16 can be replaced with _CHECK_STACK_SPACE 20.

guard makes more sense, but it needs to be precisely defined before we add it.

guard is a misnomer I think, I will likely rename it to passthrough. Basically for correctness' sake, the abstract interpreter invalidates all mutable type information gained at the boundaries between pure and impure instructions. The reasoning is that the impure instruction could have modified it. E.g.

a.attr
b()
# Can't use the same type information here. Needs to guard again.
a.attr

However, for passthrough instructions, this won't happen.

Whether the second a.attr can be replaced with the result of the first lookup depends on what global guards have been inserted. For example, if a were a class and we added a type watcher on that class to invalidate the trace, then we could make assumptions about a.attr.

The point is this sort of reasoning is as much or more a property of the optimizer than the micro-op.

...
The point is this sort of reasoning is as much or more a property of the optimizer than the micro-op.

Yes, but the point is that we still need some sort of passthrough annotation. I'm not saying I'm adding it just for the optimizer. We just need some way to signal to the abstract interpreter that some things just move data around and don't transform it. I'm giving an example of how the information is useful for the optimizer. I'm not saying that is strictly the use case for it. Another example of a property we infer is that the abstract interpreter treats passthrough as having the same value numbering right now, and that is the most important part. Whereas impure creates new numbers.

Nothing is known initially when optimizing, but any instruction can potentially become redundant as more is known about the state of the program. _CHECK_STACK_SPACE can be eliminated:

_CHECK_STACK_SPACE 20; _CHECK_STACK_SPACE 16 can be replaced with _CHECK_STACK_SPACE 20.

I really dislike the example you gave. In reality that sequence of instructions will never occur like that -- in practice we know a _CHECK_STACK_SPACE always precedes a _PUSH_FRAME so that means it's always needed. If the frame is inlined, the _CHECK_STACK_SPACE will be gone. So there will never be two consecutive _CHECK_STACK_SPACE 20; _CHECK_STACK_SPACE 16 that occur from bytecode. The only way I can see to "eliminate" it is by merging them into one giant one at the top.

In any case, what you said doesn't disagree with my new/correct definition:

The more correct definition of mandatory is that it cannot be const evaluated or type prop eliminated. An example is _CHECK_STACK_SPACE.

I don't think _CHECK_STACK_SPACE can be const evaluated or type prop eliminated.

I think the fact that this is causing so much confusion and pushback is a sign that the annotation name is misleading. I think a better name might be no_abstract_body or no_trivial_elimination or something better to signal my new definition. Any thoughts? The main idea is that pure automatically causes the abstract interpreter to try to const/type eliminate it (because by definition, that should be safe if an op is pure, but in reality these operations depend on runtime state of some sort so are not truly pure).

Also a comment on

Whether the second a.attr can be replaced with the result of the first lookup depends on what global guards have been inserted. For example, if a were a class and we added a type watcher on that class to invalidate the trace, then we could make assumptions about a.attr.

Which is why I said above:

invalidates all mutable type information gained at the boundaries between pure and impure instructions

The scenario you pointed out above is counted as immutable type information in the type system. So it won't be invalidated.

In any case -- I think bikeshedding the name is actually a good thing here. If you're confused by the names they need to be renamed so I don't inadvertently confused more people.

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