Instead of emitting the "restore callee-saved registers and return"
sequence again and again, just emit it once at the end of the generated
code, and have everyone jump to it.
This is a code size optimization that saves 207KiB on Kraken/ai-astar.js
This restores the bytecode interpreter's original call exception
throwing behaviour to the JIT.
This also fixes 8 of the 10 failing test-js tests when running with the
JIT enabled.
This replaces the existing sized immediate operands with a unified
immediate operand that leaves the size handling to the assembler,
instead of the user.
This has 2 benefits:
1. The user doesn't need to know which specific operand size the
instruction expects when using it
2. The assembler automatically chooses the minimal operand size that
fits the given value, resulting in smaller code size without any
additional effort from the user. While the change is small, it still
has a noticeable effect on performance (since it increases the I$ hit
rate), resulting in 5% speedup on kraken a-star.
As it turns out, cxx_to_boolean() may return "bool" as other values
than just 0 or 1. This happens when the C++ compiler decides to only
update the AL portion of the RAX return value register instead of
the whole thing.
If a mov instruction is meant to be patchable, we don't want to rewrite
it as a xor, since that removes the slot where we'd patch in the right
value later.
Also, make sure to set both size bits in the REX prefix for xoring a
register with itself.
When we know the value is a positive Int32 less than 0x7fffffff,
it's safe to just add 1 to it and use that as the final result.
This avoids the work of re-adding the INT32_TAG.
Compiler now has a BasicBlockData struct for each BasicBlock. The struct
contains all the stuff that we previously stored with the
Bytecode::BasicBlock.
This uses a new branch_if_both_int32() helper.
It's interesting to note that we can compare encoded Int32 values
without stripping the INT32_TAG, since it doesn't affect signedness
of values.
We now generate a fast path for cached `this` values. The first time
`this` is resolved within a function, we call out to C++, but then
all subsequent accesses will hit the cache in Register::this_value().
This necessitated making the JIT::Compiler aware of the current
Bytecode::Executable, since that's where all the string literals are
held, but that seems like a good thing.