This helps us avoid accidentally clobbering flags between two instructions
when the flags are expected to be maintained. Dolphin will of course crash
immediately, but at least it will crash loudly and alert us of the mistake,
instead of forcing hours of bisecting to find the subtle way in which the JIT
has managed to sneak a flag-modifying instruction where there shouldn't be one.
That commit reorganized fastmem a bit; I wrote it before the patch to
support fastmem in JitIL landed, and forgot to edit it to account for
the fact. Since JitILBase now derives from Jitx86Base, the HandleFault
override can just be removed.
Also correct behavior with regards to which bits in XER are treated as zero
based on a hwtest (probably doesn't affect any real games, but might as well
be correct).
This should dramatically reduce code size in the case of blocks with
lots of branches, and certainly doesn't hurt elsewhere either.
This can probably be improved a good bit through smarter tracking of register
usage, e.g. discarding registers that are going to be overwritten, but this
is a good start and should help reduce code size and register pressure.
Unlike that sort of change, this is a "safe" patch; it only flushes registers,
which can't affect correctness, unlike actually discarding data.
As part of this, refactor PPCAnalyst to support distinguishing between
float and integer registers (to properly handle instructions that access
both, like floating-point loads and stores).
Also update every instruction in the interpreter flags table I could find
that didn't have all the correct flags.
When a game was running and someone opened the video dialog, it would crash. This is because the preprocessor macro should have been __APPLE__ not _APPLE_
Fixes issue 7644.
These ID values would clash with the window parent IDs of all the actual debugger panes (they are in the 350 range as well).
For example, attempting to show and then close the memory window would cause an assertion, because it would attempt to destroy the text control for searching through memory, rather than destroying the actual parent window it's attached to.
These IDs are only used locally, so their value doesn't matter.
