I.e. flush pokes before running an EFB peek, if the cache tile isn't present. If the cache tile is present, then EFB pokes should have been written to the cache tile and thus don't need to be flushed.
This saves the GUI from having to manually call SDIO_EventNotify.
With that out of the way, we can let users change the
"Insert SD Card" setting on Android while a game is running.
Previously, when Pause at End of Movie was disabled, the game would continue running as it should, but the menu bar would think the game was paused, showing the play button instead of the pause button. To make things worse, clicking the play button would then restart the game, instead of pausing or doing nothing. F10 paused/unpaused as normal, though.
The old behavior was essentially to enable stepping/pause mode (via `CPU::Break()`) and then if Pause at End of Movie was disabled, to un-pause on the host thread (via `CPU::EnableStepping(false)`). For reasons which aren't entirely clear to me, the first one notified the menu bar (through the `Host::UpdateDisasmDialog` callback, not the `Settings::EmulationStateChanged` one), and the second did not. In any case, this approach does not particularly make sense; I don't see any reason to pause and unpause if Pause at End of Movie is disabled; instead, we should only pause when Pause at End of Movie is enabled.
This behavior was probably introduced in c1944f623b, though I haven't tested it.
directly_mapped_vars was added in #69 (4129b30494), but for some reason FIFO_BP_LO/HI were split out from it in in #885 (65af90669b). As far as I can tell, this code (and the code that existed at the time) is identical, so there's no reason to have it handled separately.
In a code block where a guest register is accessed at least twice and the
last access is a write and the register is not discardable immediately
after the second-to-last instruction (perhaps there is an instruction
in between that can cause an exception), currently Dolphin's JITs will
flush the register after the second-to-last instruction.
It would be better if we replaced the flush after the second-to-last
instruction with a flush that only happens if the exception path is
taken. This change accomplishes that by marking guest registers as
"in use" not just when they are used as inputs but also when they are
used as outputs, preventing the loop in DoJit from flushing the
register until after the last access.
This makes codegen faster (by perhaps 10-20% in the case of Jit64,
I didn't measure too closely), which helps speed up NBA Live 2005
a little. But the game still has serious performance issues.
The DSP JIT only applies on x64, so if it doesn't work on esoteric compilers then that's not a problem. (And if it fails to compile, then it'll still produce an error on that platform, just no warnings on other platforms)
Mai M