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

Jit64: Don't use fregsIn in HandleNaNs #11139

Merged
merged 1 commit into from Nov 20, 2022

Conversation

JosJuice
Copy link
Member

@JosJuice JosJuice commented Oct 8, 2022

fregsIn will include FD for double-precision instructions, since for dependency tracking purposes the instruction does read the upper half of FD. This is not what we want in HandleNaNs.

The consequence of this bug is that if an instruction was supposed to output a NaN and FD happens to contain a NaN and FD happens to be the same register as an unused register in the instruction encoding, the NaN in FD could get used as the output instead of the correct NaN. This isn't known to affect any games, which isn't especially surprising considering that there's only one game that needs AccurateNaNs anyway.

fregsIn will include FD for double-precision instructions, since for
dependency tracking purposes the instruction does read the upper
half of FD. This is not what we want in HandleNaNs.

The consequence of this bug is that if an instruction was supposed to
output a NaN and FD happens to contain a NaN and FD happens to be the
same register as an unused register in the instruction encoding, the
NaN in FD could get used as the output instead of the correct NaN.
This isn't known to affect any games, which isn't especially surprising
considering that there's only one game that needs AccurateNaNs anyway.
Copy link
Contributor

@AdmiralCurtiss AdmiralCurtiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah seems fine.

The inconsistent usage of int and u32 for registers bothers me a bit but looking through the code this is far from the only place where it's like that so whatever.

I also wonder if it would be worth it to replace usages of std::vector where the maximum size is a known low value (like here, input is a maximum of 3 values...) with something like a boost static_vector, but that's very much out of scope of this PR.

@JMC47 JMC47 merged commit 22bcf13 into dolphin-emu:master Nov 20, 2022
11 checks passed
@JosJuice JosJuice deleted the jit64-nans-no-freg branch November 20, 2022 18:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants