Move ImGui::End() calls out of if(ImGui::Begin()) blocks.
Quoting from ImGui::Begin's function comment in imgui.cpp:
"You always need to call ImGui::End() even if false is returned."
In practice this didn't cause problems because the windows don't have
title bars and thus can't be collapsed, and so the block containing
::End would always run, but let's do it the right way.
You can encode a shifted 12-bit immediate in a SUB instruction on ARM64.
We exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52a00218 mov w24, #0x100000 ; =1048576
0xcb180379 sub x25, x27, x24
After:
0xd1440379 sub x25, x27, #0x100, lsl #12 ; =0x100000
You can encode a 12-bit immediate in a SUB instruction on ARM64. We can
exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x5280003a mov w26, #0x1 ; =1
0xcb1a033b sub x27, x25, x26
After:
0xd100073b sub x27, x25, #0x1
While we cannot always avoid materializing immediates, we can still
inspect the most significant bit and potentially skip sign extension.
This can sometimes save an instruction.
Before:
0x5280003a mov w26, #0x1 ; =1
0x93407f5b sxtw x27, w26
0xcb38c37b sub x27, x27, w24, sxtw
After:
0x5280003a mov w26, #0x1 ; =1
0xcb38c35b sub x27, x26, w24, sxtw
Before:
0x52a20018 mov w24, #0x10000000 ; =268435456
0x93407f79 sxtw x25, w27
0xcb38c339 sub x25, x25, w24, sxtw
After:
0x52a20018 mov w24, #0x10000000 ; =268435456
0x93407f79 sxtw x25, w27
0xcb180339 sub x25, x25, x24
You can encode a shifted 12-bit immediate in an ADD instruction on
ARM64. If the negated constant fits in this range, we can exploit this
to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52bff01a mov w26, #-0x800000 ; =-8388608
0x93407f1b sxtw x27, w24
0xcb3ac37b sub x27, x27, w26, sxtw
After:
0x93407f1b sxtw x27, w24
0x9160037b add x27, x27, #0x800, lsl #12 ; =0x800000
You can encode a 12-bit immediate in an ADD instruction on ARM64. If the
negated constant fits in this range, we can exploit this to avoid
materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x12800019 mov w25, #-0x1 ; =-1
0x93407f5b sxtw x27, w26
0xcb39c37b sub x27, x27, w25, sxtw
After:
0x93407f5b sxtw x27, w26
0x9100077b add x27, x27, #0x1
You can encode a shifted 12-bit immediate in a SUB instruction on ARM64.
Constants in this range do not need to be sign extended, so we can
exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52a00099 mov w25, #0x40000 ; =262144
0x93407f7a sxtw x26, w27
0xcb39c35a sub x26, x26, w25, sxtw
After:
0x93407f7a sxtw x26, w27
0xd141035a sub x26, x26, #0x40, lsl #12 ; =0x40000
You can encode a 12-bit immediate in a SUB instruction on ARM64.
Constants in this range do not need to be sign extended, so we can
exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52800416 mov w22, #0x20 ; =32
0x93407f78 sxtw x24, w27
0xcb36c318 sub x24, x24, w22, sxtw
After:
0x93407f78 sxtw x24, w27
0xd1008318 sub x24, x24, #0x20
A number of settings in the `debugger` group were wrongly using a newly
constructed `QSettings` object instead of the singleton object that
`GetQSettings()` provides.
This made the application create a spurious, extra configuration file in
the user directory:
```
~/.config/Dolphin Emulator/dolphin-emu.conf
```
Notice that, by default, the application configuration files are stored
in `~/.config/dolphin-emu`; not in `~/.config/Dolphin Emulator`.
Adding a community-requested list of Gecko and Action Replay codes to the allowlist. Many of these codes were from the wiki and are being added to Dolphin's repo for the first time.
Change the displayed controls in the TAS Input window when the
controller's extension (including MotionPlus) is changed.
This previously required restarting Dolphin after the attachment was
changed, as the controls were never updated after the WiiTASInputWindow
was created at Dolphin startup.
When I wrote 71e9766519, there was an interaction I didn't take into
account: When setting eq, SetCRFieldBit assumes that all bits in the
passed-in host register except the least significant bit are 0. But if
we use EON or ORN, all bits except the least significant bit get set to
1. This can cause eq to end up unset when it should be set.
This commit fixes the issue.
crandc is unaffected by the issue because the "1" bits get ANDed with
"0" bits from the first operand.
Note that in practice, we never have both bits_1_to_31_are_set and
negate at once, so while it looks like this commit adds an extra AND
instruction in some cases, those cases don't happen in practice, meaning
this fix shouldn't affect performance.
OatmealDome