Split comparison ops into "object" and "bit" versions.

[markshannon]

Comparison operations are commonly followed by POP_JUMP_IF_(TRUE|FALSE)

Would could split each ${compare} opcode into ${compare}_OBJECT and ${compare}_BIT.

{compare} can be either COMPARE_ and IS_.

The ${compare}_OBJECT would behave as the current ${compare}.
The ${compare}_BIT form would perform the comparison, but instead of pushing the result of the comparison, would set some notional VM flag in the same way as a CISC processor does.

Then we would then need two BRANCH_IF_(TRUE|FALSE) instructions and insist that ${compare}_BIT and BRANCH_IF_(TRUE|FALSE) always form pairs:

• ${compare}_BIT must be followed by BRANCH_IF_(TRUE|FALSE)
• BRANCH_IF_(TRUE|FALSE) must be preceded by a ${compare}_BIT.

We can then convert:

    ${compare}
    POP_JUMP_IF_TRUE

to

    ${compare}_BIT
    BRANCH_IF_TRUE

The implementation of ${compare}_BIT can perform the jump as well, since it is guaranteed to be followed by BRANCH_IF_(TRUE|FALSE). This avoids the need to create the temporary boolean, and saves an instruction dispatch.

We already specialize compare-branch pairs in a fairly ad-hoc way. Adding these new instructions will give a slight speed boost to unspecialized code and allow us to specialize compare-branch pairs in a less adhoc fashion.

[gvanrossum]

Why not introduce {compare}_AND_JUMP_IF_{TRUE|FALSE} instructions?

[brandtbucher]

Wouldn't that need like 19 instructions though? (EQ|NOTEQ|LT|LTE|GT|GTE|IS|CONTAINS)_AND_JUMP_IF_(TRUE|FALSE), COMPARE_OP, IS_OP, and CONTAINS_OP. Unless we wanted to encode both the op and the jump target in the oparg... hm.

Mark's scheme only needs 8: (COMPARE|IS|CONTAINS)_(OBJECT|BIT) and BRANCH_IF_(TRUE|FALSE) (though it looks like CONTAINS_(OBJECT|BIT) is omitted?). And the branch is logically part of the *_BIT instruction, so they can execute as one anyways.

[gvanrossum]

Oh, it's because COMPARE has an oparg that indicates the comparison operation. (Though I don't recall why IS and CONTAINS aren't also encoded that way -- perhaps because they don't call into RichCompare?)

[markshannon]

It is because IS, CONTAINS, and COMPARE are three quite different operations.
IS_OP is way faster than COMPARE_OP as it is just a pointer comparison.

[markshannon]

This proposal would only need 4 additional instructions (including CONTAINS which I omitted earlier):
COMPARE_BIT, IS_BIT, CONTAINS_BIT, BRANCH_ON_BIT.

We can encode the direction of the branch in the test.
E.g. supposed we have COMPARE_OP '>' ; BRANCH_IF_FALSE, we could translate that to:
COMPARE_BIT ('>' | INVERT_FLAG); BRANCH_ON_BIT
The IS_OP and CONTAINS_OP already include an "invert" oparg, so that we can encode in and not in using the same instruction.

As Brandt says, the compiler can guarantee that the second instruction is BRANCH_ON_BIT, so the pair can be treated as a superinstruction.