This is possible now that EmitBackpatchRoutine lets the caller choose
addr register.
Note: The removed MOV is actually traded for one added MOV in farcode.
When EmitBackpatchRoutine emits slow access code for a load, RS must not
be in scratch_gprs/scratch_fprs if we have memchecks (otherwise the
memcheck exit won't be able to save RS properly), and RS must be in
scratch_gprs/scratch_fprs if we don't have memchecks (otherwise RS will
be restored to the value it had before the load, overwriting the result
of the load). Let's save callers from having to think about this by
embedding the relevant logic inside EmitBackpatchRoutine.
This cuts down on how much callers have to think about what registers
EmitBackpatchRoutine is using. Also, by allocating registers dynamically
instead of using a fixed set of registers, we improve codegen in cases
where the fixed registers are taken but other registers are free.
(These improvements don't apply to the emitting_routine == true case,
where everything still works like before by necessity.)
Preparation for the next commit, which will make EmitBackpatchRoutine
allocate registers on its own. Because the register allocation will
change during the call to EmitBackpatchRoutine, the set of GPRs/FPRs to
push can't be computed prior to the call, so let's compute them during
the call instead.
Creates a layer outside the game config layer system and passes it to the created gfx widows, so as to not interfere with the global config system.
Supports multiple game properties being open at once.
Supports editing while a game is playing, but the options only save and update the active game when the window is closed.
Right-clicking will remove a property from the game ini.
Prefer BLENDVPD over VBLENDVPD if the latter doesn't save any
instructions.
VBLENDVPD allows separate source and destination registers, which can
eliminate a MOVAPD/MOVSD. However, on Intel since Skylake, VBLENDVPD
takes additional uops to execute compared to BLENDVPD (according to
https://uops.info). On AMD and older Intel microarchitectures there is no
difference.
The read thread could call Reset, which in turn tried to join the read
thread, leading to a SIGABRT. This manifested as Dolphin consistently
crashing when disconnecting a GC adapter and having a chance of crashing
a few seconds after connecting a GC adapter.
Now that patches and codes are enabled on a case by case basis, remove patcher code blocking codes entirely in hardcore mode, and reword the warning to be more accurate.
This apparently didn't compile on macOS six years ago before c++20, but
it should be fine by now.
While I'm at it, make the constants upper case per convention.
