GH-127809: Fix the JIT's understanding of **#127844
GH-127809: Fix the JIT's understanding of **#127844brandtbucher merged 8 commits intopython:mainfrom
**#127844Conversation
brandtbucher
added
interpreter-core
brandtbucher
requested review from
Fidget-Spinner and
markshannon
as code owners
Python/optimizer_bytecodes.c
Outdated
| goto binary_op_done; | ||
| } | ||
| if (oparg == NB_POWER || oparg == NB_INPLACE_POWER) { | ||
| // This one's fun: the *type* of the result depends on the *values* |
There was a problem hiding this comment.
I'm not convinced that this is worth the complexity for anything other than integer constant right hand sides.
It the rhs is an int constant, then the result is the type of the lhs (for ints and floats) otherwise, "not known".
Calculating any other result is so slow that the cost of the guard we could potentially remove is negligible.
There was a problem hiding this comment.
Doesn't a negative int rhs produce a float?
>>> 3 ** -1
0.3333333333333333
Your point may still stand that it's too expensive, but unfortunately the assumption that if rhs is an int we can determine the result without looking at the value doesn't hold.
|
Alright, I added some more comments and made it quite a bit simpler (only covering the "easy" cases). Let me know if it looks good now. |
markshannon
left a comment
markshannon
left a comment
There was a problem hiding this comment.
Looks correct.
Still quite complex, but a lot more reasonable than the original version.
Let's see if the ASAN failure was just a glitch.
4 participants
It's more complex (ha) than we originally thought.
I think it's probably worth trying to do the "smart" thing here, since exponents with at least one constant part are reasonably common. But if others think the additional logic in the optimizer is too much, we can just say that the result of
**an**=is unknown (even when it may technically be knowable):The runtime cost would be an additional guard in JIT code following a
**or**=.**is wrong #127809