- InvalidateFlags pseudo-op is a hint for the Dead Flags Elimination pass that flags are not needed past that point
- Adds a new option, --abi-local-flags, that invalidates the flags on CALLs or RETs. This might break code that doesn't follow the ABI rules.
This dumps the IR before and after optimizations
--dump-ir can be
"no" -> Do not dump
"stderr" -> Dump to stderr
"stdout" -> Dump to stdout
"some/path" -> Dump to "some/path/$GuestRip-pre.ir" and "some/path/$GuestRip-post.ir"
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.
Ryan Houdek