gh-131798: JIT: Narrow the return type of _BINARY_OP_SUBSCR_STR_INT to str#132153
gh-131798: JIT: Narrow the return type of _BINARY_OP_SUBSCR_STR_INT to str#132153brandtbucher merged 3 commits intopython:mainfrom
_BINARY_OP_SUBSCR_STR_INT to str#132153Conversation
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. |
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
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 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. |
brandtbucher
left a comment
There was a problem hiding this comment.
Looks good. Want to tidy up the test before I merge?
Co-authored-by: Brandt Bucher <brandtbucher@gmail.com>
|
Thanks for the clarification about the meaning of constants in the JIT! That's an important distinction to make for sure. |
I tested this by finding another instruction which contains a unicode guard, in this case
BINARY_OP_ADD_UNICODEand checking that the guard is removed if one of the operands is the result of_BINARY_OP_SUBSCR_STR_INT. Let me know if there's a better way to test this!I also noticed that some other uops like
_BINARY_OP_ADD_UNICODEcheck 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.