This was sort of partially worked around.
The issue comes down to REX.W and Operand size prefix ordering on an
instruction.
When an instruction has both prefixes, then the one that has occured
later will overwrite the previous one.
Additionally in the case of 66h being reused as an escape prefix, we
needed to ignore it in this case.
The previous workaround was that if an instruction happened to have both
widening and narrowing, then widening would win(for MODRM args),
but then later on in the instruction decoding the literal constant
decoding would properly check which order the flags came in.
This resulted in literal constants working, but not modrm bytes
Instead replace the "last" flag handling with a two deep stack that we
can push and pop the flags correctly on to it, this ensures that the
flags stay around in the 66h ignoring mode (so widening doesn't get
obliterated).
This effects every instruction that supports REX.W and 66h Operand size
prefix, so it could be fixing some unknown bugs elsewhere.
Very specifically this one was found in OpenSSL, because it looks like
GCC is padding a mov instruction with 66h.
Instruction Examples:
Only difference is the prefix order being swapped
0x00000000 4 66488b1f mov rbx, qword [rdi]
0x00000004 4 48668b1f mov bx, word [rdi]
AArch64's ADDV instruction doesn't support 8byte elements, it instead
needs to use ADDP(scalar) for the operation.
Fixes an assert and minor behaviour difference there
LORegion is a requirement of ARMv8.1, but the hypervisor of the c630
isn't exposing the identification register correctly.
If the host supports atomics, just assume it supports LORegions as well
Fixes an assert when building vixl in debug
Allows us to register host and guest signal delegators.
Currently only host signals are handled, guest signal delegation will
take a bit of work still.
Previously the ARM64 JIT didn't support cache clearing at all.
This adds support for clearing the JIT cache while keeping dispatcher
helpers around and the ASM dispatcher alive.
Improves compilation time by multiple minutes
Clang was taking multiple minutes to compile JIT.cpp for ARM.
This drops it down to a handful of seconds instead.
No functional behaviour change, only movement.
JIT compile times might deviate slightly moving from a switch to a jump
table, but will be negligible in either direction.
The break ir op is actually a block ender and it happened that in
regular code paths they were already ending the blocks correctly.
This enforces block ending in the Unimplemented op so multiblock still
generates the invalid code path correctly and it compiles.
We hit these a few times in multiblock for times in the code where it is
checking for CPU features and choosing a code path depending on CPUID
results.
Potentially these could be made in to no-ops since we'll never hit these
codepaths in practice, but it is nicer to break in case we actually do
hit one of these paths.
There's some history for this instruction. It is not in the official
instruction documentations from AMD or Intel but it is supported on
almost every x87 supporting CPU (I think there was some Cyrix that
missed it?)
This was originally implemented by accident on the Intel 80287 CPU.
It was then periodically documented in random documentation.
The instruction behaves exactly like FFREE but then pops the stack after
the operation.
For our current implementation of FFREE, which is a NOP, we just need to
pop the stack.
This must of have been a copy and paste error, I didn't even have this
instruction on my list of implemented instructions.
It definitely isn't converting to a GPR
32bit apps are setting GS register that I saw.
64Bit applications can also technically use these instructions but it
has some major limitation that causes applications to never use them
These can only be implemented as acquire/release exclusive loops on
ARMv8.0 so they end up looking pretty disgusting.
This is more for compatibility for testing than anything. I'm not
expecting ANY ARMv8.0 device to get decent performance
When the `BT mem` operation was accessing memory where the bit offset
wasn't a multiple of the access size, then we were dividing the offset
by bytes and accessing bits at `mem[byteOffset] &= (BitOffset)`.
BitOffset wasn't adjusted to compensate for the access size being added
to the address.
Causing a mismatch of testing the wrong bits. Unit tests didn't capture
this.
Trying to run glxgears on i965/iris showed extensive corruption because
of it though.
Theoretically the REP case can be optimized if it is known not to fault,
but that is one legitimate use case of this instruction.
This is just to ensure that we have this instruction covered, it hasn't
been encountered in a real program yet.
Stefanos Kornilios Mitsis Poiitidis