GH-127809: Fix the JIT's understanding of **

[brandtbucher]

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):

        if (oparg == NB_POWER || oparg == NB_INPLACE_POWER) {
            res = sym_new_unknown(ctx);
        }
        else if (oparg == NB_TRUE_DIVIDE || oparg == NB_INPLACE_TRUE_DIVIDE) {
            res = sym_new_type(ctx, &PyFloat_Type);
        }
        else if (sym_matches_type(left, &PyLong_Type) && sym_matches_type(left, &PyLong_Type)) {
            res = sym_new_type(ctx, &PyLong_Type);
        }
        else {
            res = sym_new_type(ctx, &PyFloat_Type);
        }

The runtime cost would be an additional guard in JIT code following a ** or **=.

• Issue: The JIT's understanding of ** is wrong #127809

[markshannon]

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.

[mdboom]

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.

[brandtbucher]

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]

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.