I also noticed that some other uops like _BINARY_OP_ADD_UNICODE check if the operands are constants. Should we add it here as well? I don't know if we gain much from that though, code like 'foo'[0] is not very common.

The constant checking is sort of a relic. We don't even do anything with it. So it's fine to leave it out for now.

All commit authors signed the Contributor License Agreement.

I don't know if we gain much from that though, code like 'foo'[0] is not very common.

Just a quick note on this: "constant" here means anything the JIT knows to be a constant value at runtime, not just things that are statically constant in the source. So it could be something like MODULE_GLOBAL[len(foo) - 1], for instance.

The constant checking is sort of a relic. We don't even do anything with it.

I disagree, constant symbols are pretty powerful, and we should be using them more. For example, knowing constant values currently allows us to entirely remove conditional branches, type version checks, etc. @savannahostrowski also added the new _POP_TWO_LOAD_CONST_INLINE_BORROW instruction (and is in the process of using it in the remaining _BINARY_OP_* and _COMPARE_OP_* uops, which allows us to remove these operations entirely when the result is immortal).

I agree that it's probably not worth adding to this uop specifically (at least not without some examples of real-world code it would optimize), but I do think that tracking constant values in general is a good thing.

Thanks for the clarification about the meaning of constants in the JIT! That's an important distinction to make for sure.