mirror of
https://github.com/dolphin-emu/dolphin.git
synced 2025-12-16 04:09:39 +00:00
0c024de591
We have an optimization where the guest carry flag is kept in the host carry flag between certain back-to-back pairs of integer instructions. If the second instruction falls back to the interpreter, then FallBackToInterpreter should flush the carry flag to m_ppc_state, otherwise the interpreter reads a stale carry flag and at some later point Jit64 trips the "Attempt to modify flags while flags locked!" assertion. An alternative solution would be to not store the guest carry flag in the host carry flag to begin with if we know the next instruction is going to fall back to the interpreter, but knowing that in advance is non-trivial. Since interpreter fallbacks aren't exactly intended to be super optimized, I went for the flushing solution instead, which is how JitArm64 already works. In most cases, the emitted code shouldn't even differ between these two solutions. Note that the problematic situation only happens if the first integer instruction doesn't fall back to the interpreter but the second one does. This used to be impossible because there's no "JIT disable" setting that's granular enough to disable some integer instructions but not all, but with the constant propagation PR, it's possible if constant propagation is able to entirely evaluate the first instruction but not the second. |
||
|---|---|---|
| .. | ||
| Android | ||
| Core | ||
| DSPSpy | ||
| DSPTool | ||
| PCH | ||
| UnitTests | ||
| VSProps | ||
| .clang-format | ||
| CMakeLists.txt | ||
| dolphin-emu.sln | ||