All of the ops that were relying on a 64bit memory offset were being
downgraded to 32bit.
Abuses the XMM_FLAGS option a bit to indicate that it shouldn't
downgrade the 64bit size flag. Which isn't an issue since all these
operations can't encode a register since modrm_r is used for table
decoding
Based on @phire's idea, Inline constants are constants that can be used as imms in instructions.
This
- Adds OP_INLINECONSTANT to represent them in the IR
- Modifies the ConstProp pass to transform OP_CONSTANT to OP_INLINECONSTANT based on per-platform heuristics
- Modifies the backends to use imms
- Supported opcodes: Add, Sub, Lsl, Lsr, Asr, Ror, Rol
RIP Literal isn't actually RIP literal on 32bit, it is RIP absolute.
64bit treats the 32bit as a signed offset, while 32bit treats it as a
32bit unsigned offset
This interface is for native host code to be able to call back in to JIT
to execute guest code.
This is mainly for thunks but could be used for other purposes.
This can cross a couple ABI boundaries so one must be careful when
calling in to this
This requires implementing custom ASM dispatchers for the interpreter
side of things so it works correctly.
Allows all of our CPU backends to safely support signaling.
This is a bit of a nightmare change and requires rethinking logic about
debugging in some instances.
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]
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
This is just a virtual number that the guest can query through the
various means. Will affect mesa with how many helper threads it
generates at the very least
This implements support for 130 of the 132 x87 ops as interpreter
fallbacks.
The two missing ops are the BCD load and BCD store instructions and can
be implemented another time.
This allows us to no longer have to rely on a libstdc++ modification to
handle their usage of long double. This instead works entirely through
using `long double` directly in the interpreter. Which will either use
real x87 on an x86 host. Or in the case of ARM devices, fall down
glibc's long double soft float path.
This doesn't necessarily need to be quick right now. It's more important
to have the compatibility improvement from this.
As we run more threaded applications it is becoming apparent that this
needs to be fixed now.
This duplicates the FrontendDecoder and Passmanager per thread so they
no longer block each other while compiling.
Increases a bit of memory usage but completely worth it.
The IRHeader itself contains a flag for if a block should fallback to
the interpreter.
This is necessary for the case that an IR is loaded and the Frontend
object no longer has the data necessary to know if it should do an
interpreter fallback.
This is super useful for bisecting JIT versus Intepreter failures, and
also cases where falling back to intepreter for compatibility is a lot
more simple than wiring things through the JIT (ala x87)
This isn't currently utilized, but will be once x87 work lands
32bit x86 memory accesses require going through the GDT and has syscalls
that support setting these.
The GDT isn't a flat address space like in x86-64, so we actually need
to support this.
The Passmanager passes need very little or zero x86 knowledge to do
their work. They don't need the x86 OpDispatcher handling code at all.
Convert this entirely over to using the IREmitter class so it can
actually optimize IR code from the IRLoader frontend
This class does IR emitting and some basic handling of IR specific
tasks.
This is going to be used to split the x86 OpDispatcher from the IR
emission so the IR emitter can be passed around without caring about x86
dependencies.
Ryan Houdek