If it finds itself not in the simple case it specialized for, it reverts back to the unspecialized case. In JIT compiler terms, this is called a "guard"
But isn't this the same as what LOAD_ATTR also does? It first checks the simple case, and if that fails, it goes the complex fallback route. Why does this need a new op? Or why would the standard LOAD_ATTR not do this?
Or are there multiple versions of the compiled function, and it modifies the bytecode per each call of the function?
The issue is that there are many different "simple cases". The more checks for "fast paths" you add, the more overhead of individually checking for them.
Also consider that:
- this is more branch predictor friendly (a generic opcode encounters many different cases, while a specialized opcode is expected to almost never fail),
- the inline cache has limited space and is stateful (imagine it's a C union of cache structs for different fast paths). If your "generic" LOAD_ATTR found a simple case B, it'd still need to ensure that its inline cache was actually primed for simple case B. This is not the issue with specialized opcodes; the cache is set to correct state when the opcode gets specialized.
How can it do that? The `self` variable could be anything, or not?