Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JitArm64: Update registers last used before start of instruction #9472

Merged
merged 3 commits into from Jan 27, 2021

Conversation

JosJuice
Copy link
Member

Let's reset m_last_used for each register that will be used in an instruction before we start allocating any of them, so that one of the earlier allocations doesn't spill a register that we want in a later allocation.

See the individual commits for details.

If the register pressure is high when allocating registers,
Arm64FPRCache may spill a guest register which we are going to
allocate later during the current instruction, which has the
side effect of turning it into double precision. This will have
bad consequences if we are assuming that it is single precision,
so let's add some asserts to detect if that ever happens.
It obscures more than it helps in my opinion.
Let's reset m_last_used for each register that will be used
in an instruction before we start allocating any of them,
so that one of the earlier allocations doesn't spill a
register that we want in a later allocation. (We must still
also increment/reset m_last_used in R and RW, otherwise we
end up in trouble when emulating lmw/stmw since those access
more guest registers than there are available host registers.)

This should ensure that the asserts added earlier in this
pull request are never triggered.
@leoetlino leoetlino merged commit 2d75b0d into dolphin-emu:master Jan 27, 2021
10 checks passed
@JosJuice JosJuice deleted the jitarm64-unexpected-double branch January 27, 2021 11:44
@JosJuice
Copy link
Member Author

JosJuice commented Jan 27, 2021

Apparently the asserts I added are getting triggered in certain games (e.g. Wind Waker) :/

Will try to investigate.

EDIT: All the instances I've found should be fixed by PR #9478.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants