- 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"
These two instructions pop the x87 stack twice which we didn't support
Repurposes the dead pop template argument to be a "pop twice".
Everything else falls down the table flag information comparison
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
These are being used unconditionally by the steam client (browser?) and
Minit.
Push out the initial implementation without unit tests just to get
further.
Would be nice to figure out why these are using these ops instead of
checking if it is supported.
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
A couple of instructions were incorrectly marked as mem offset.
Fixes the mem offset literal size which is only modified with the
address size modifier.
Previously this was causing these instructions to narrow based on
operand size override incorrectly
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
Java VM uses this to determine if the CPU is new enough to be a 486 or
newer.
Also fixes some comment text.
Java VM scans all the leafs for hypervisor entries
Instead of adding directly which was causing our CPUID map to grow to
1500 entries.
Do the correct CPUID thing and return zeroes for non-understood leafs.
Gives us the same result since we cover almost all leaves with it anyway
