Integer binary ops design discussion

[TH3CHARLie]

Start with a simple example:

def foo(left: int, right: int) -> bool:
     result = left == right
     return result

In the current C backend, it will generated C code(fully inlined except the out of memory handling):

#define CPY_INT_TAG 1

if (!(left & CPY_INT_TAG)) {
    result = left == right;
} else {
    if (!(right& CPY_INT_TAG)) {
        result = false;
    } else {
       result = PyObject_RichCompareBool((PyObject *)(left & ~CPY_INT_TAG),
                                              (PyObject *)(right & ~CPY_INT_TAG), Py_EQ);
        if (result == -1) {
            CPyError_OutOfMemory();
        }
    }
}
return result

So I guess the IR would look like

r0 = CPY_INT_TAG
r1 = BitwiseAnd(left, r0)
if not r1 goto L1 else goto L2

L1:
r2 = BinaryEq(left, right)
result = r2

L2:
r3 = BitwiseAnd(right, r0)
if not r2 goto L3 else goto L4

L3:
result = false

L4:
r4 = BitwiseNot(r0)
r5 = BitwiseAnd(left, r4)
r6 = BitwiseAnd(right, r4)
result = PyObject_RichCompareBool(r4, r5, PY_EQ) # we can have a custom CallC to do it
r7 = BinaryEq(result, -1)
if r7 goto L5 else goto L6

L5:
CPyError_OutOfMemory()

L6:
...

Instead of generating a single PrimitiveOp, we are trying to generate several blocks/branches. BitwiseNot, BitwiseAnd, BinaryEq should all be the binary ops we'd want to add.

cc @JukkaL

[JukkaL]

it will generated C code (fully inlined except the out of memory handling)

There's no need to inline the else block, since it's only used for long integers, and we can expect them to be relatively rare. Any performance benefit from inlining isn't worth the extra code size. So this would be a sufficient level of inlining:

#define CPY_INT_TAG 1

if (!(left & CPY_INT_TAG)) {
    result = left == right;
} else {
    result = CPyTagged_IsEq_(left, right);
}
return result

This would simplify the IR significantly.

Another thing is that we'd need an explicit comparison op after the bitwise and, for example:

  r0 = 1
  r1 = BitwiseAnd(left, r0)
  r2 = 0
  r3 = BinaryEq(r1, r2)
  if r3 goto L1 else goto L2
L1:
  r2 = BinaryEq(left, right)
  result = r2
  goto Lx
  ...

The generated IR is still a bit verbose. Maybe we should support integer literals as operands so we could represent the above IR more compactly like this:

  r1 = BitwiseAnd(left, 1)
  r2 = BinaryEq(r1, 0)
  if r2 goto L1 else goto L2
L1:
  r2 = BinaryEq(left, right)
  result = r2
  goto Lx
  ...

This might be worth it, since it looks like the low-level IR will have lots of low-level integer values. (This simplification can happen later.)

[TH3CHARLie]

Actually I find that we did register binary comparison ops for short ints(check int_ops.py -> int_compare_op for more info), but they never get called(I did the search through all mypyc IR tests, only the custom short int add unsafe_short_add is used)

[TH3CHARLie]

A good entry point would be transform_op_expr in expression.py. We can either use specializers or other helpers here. The high-level logic would be:

1. check whether lhs and rhs are int
2. build the above-discussed blocks if true
3. fall back to original plan if false

[JukkaL]

Integer ops are special enough that we can just implement them in a function called from transform_op_expr instead of using AST lookup driven specializers.