Bit hacks to remove branches in JUMP instructions.

[markshannon]

A branch in the VM does not need to be a branch is the underlying C code.
The difference between a forward and backward branches is just negating the oparg.

We can use a variety of "bit hacks" to merge the code for different jumps and to avoid poorly predicted branches in the C code.

Whether this is any faster depends very much on branch prediction. For branches that are well predicted, this may well be slower.

We can encode the direction (forward/backward) and sense (jump on true/jump on false) in two bits of the opcode.

The bits should be chosen to streamline the code as much as possible.

A possible scheme for combining jump instructions

opcode & 2: 2 for forward, 0 for backward.
This means that (opcode & 2) - 1 is +1 for forward jumps, and -1 for backward jumps.
opcode & 1: 1 for "truthy", 0 for "falsy"

label_for_all_jump_is_none:
     int direction = (opcode & 2) - 1;
     int is_none = (obj == Py_None);
     int jump = is_none ^ (opcode & 1);
     int delta = (-jump) & (direction * oparg); /* delta is 0 if jump is zero */
     JUMP_BY(delta);

Eval breaker checks

For platforms where _Py_atomic_load_relaxed is cheap, e.g. x86, we want to avoid:

if (backward) {
    CHECK_EVAL_BREAKER();
}

as it expands to

if (backward) {
    if (_Py_atomic_load_relaxed(eval_breaker)) {
        goto handle_eval_breaker;
    }
}

For platforms where _Py_atomic_load_relaxed requires a memory fence, then we will want a different approach, as

if (backward) {
    if (_Py_atomic_load_relaxed(eval_breaker)) {
        goto handle_eval_breaker;
    }
}

may well be faster.

If we change the CHECK_EVAL_BREAKER() macro to CHECK_EVAL_BREAKER(back) we can factor this out of the instruction logic.