In the case of an invalid SSA destination size, the IR validation pass
would catch it and then when printing the IR it would crash with a
divide by zero.
Fixes that.
This should really be done later in a sperate PR.
1. We don't have proper unit test coverage
2. I still didn't get this right at time of removal
3. I haven't done the jit changes to go along with this.
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
Mutlblock pass that eliminates flag stores that are never read.
This is a sibling to RCLSE and will likely be absorbed by it when we add MB support there.
Add and substract were the main culprits here.
We are trying to more towards a state where:
* Every IR op can expect it isn't given extra bits
on it's input
* Every IR op never sets more bits than it's size
* All unnessicary BFEs are never emitted
* ARM doesn't have to implement special 8 and 16bit versions of IR ops
All masking required to implement 8/16bit math on
arm should be explictly generated from Opcode decoder
The IR mostly worked this way already.
The one change I needed to make was in DCSE.
DCSE needs to add an explict truncate whenever an eliminated store was
doing an implict trunctate.
We are rebranding an x86-64 illegal instruction near VIA's old ALTINST
instruction as an instruction to handle returning from guest signals
cleanly.
If this ever collides with a new x86-64 (unlikely) then we will need to
change the instruction.
This ends up looking similar to what we will do for thunk callbacks
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 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.
Stefanos Kornilios Mitsis Poiitidis