Test potential JumpTableRange optimization

[sf-jonstewart]

Instead of specifying the inclusive range of values in the JumpTableRange instruction operands, specify the operands to be the base value of the range and a length so we can go from this:

  case JUMP_TABLE_RANGE_OP:
    if (instr.Op.T2.First <= *cur && *cur <= instr.Op.T2.Last) {
      const uint32_t addr = *reinterpret_cast<const uint32_t* const>(t->PC + 1 + (*cur - instr.Op.T2.First));
      if (addr != 0xFFFFFFFF) {
        t->jump(base, addr);
        return true;
      }
    }
    break;

to

    {
      auto diff = *cur - instr.Op.T2.First;
      if (diff < instr.Op.T2.Last) {
        const uint32_t addr = *reinterpret_cast<const uint32_t* const>(t->PC + 1 + diff);
        if (addr != 0xFFFFFFFF) {
          t->jump(base, addr);
          return true;
        }
      }
    }
    break;

The latter requires fewer comparisons for the condition, and then is able to reuse the difference to avoid the subtraction in the calculation of the jump table offset. I don't have a good feel for whether this will make a meaningful difference, but jump table is likely our most executed instruction on sufficiently large programs.

[sf-jonstewart]

The latter form relies on unsigned wraparound for when *cur < instr.Op.T2.First. The result will be a number bigger than instr.Op.T2.Last. h/t https://www.youtube.com/watch?v=9tvbz8CSI8M, about 23' in.

[uckelman-sf]

We should look at making the second comparison against 0 instead of 2^32-1, since that will be a single instruction instead of a load and a comparison.

[sf-jonstewart]

@uckelman-sf Implemented. It might be a hair faster on the twain test. Or it just might be noise. Do you have a preference?