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: Correctly handle NaNs for ps_mulsX/ps_sumX #11304
Conversation
c636395
to
1c310e4
Compare
Source/Core/Core/PowerPC/Jit64/Jit.h
Outdated
| @@ -127,7 +129,8 @@ class Jit64 : public JitBase, public QuantizedMemoryRoutines | |||
| bool duplicate = false); | |||
| void FinalizeDoubleResult(Gen::X64Reg output, const Gen::OpArg& input); | |||
| void HandleNaNs(UGeckoInstruction inst, Gen::X64Reg xmm, Gen::X64Reg clobber, | |||
| std::vector<int> inputs); | |||
| const std::optional<Gen::OpArg> Ra, const std::optional<Gen::OpArg> Rb, | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if these aren't passed by reference or pointer, then the const does nothing in the declaration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I iterated on a few different approaches for how to pass the operands, and I think this was a leftover from an iteration where I was using references.
Now that I think about it, the switch away from a vector isn't actually necessary with the current approach... Any opinions on that one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really have that strong an opinion either way. It's nice to not need to heap allocate, though
Operations that have two operands and can't generate a default NaN, i.e. addition and subtraction, already have the desired NaN handling on x86. We just need to make sure to not reverse the operands. This fixes ps_sum0/ps_sum1 outputting NaNs in cases where they shouldn't. (HandleNaNs assumes that a NaN in a ps0 input always results in a NaN in the ps0 output, and correspondingly for ps1.)
1c310e4
to
2f1a8ee
Compare
HandleNaNs assumes that a NaN in a ps0 input always results in a NaN in the ps0 output, and correspondingly for ps1. This isn't the case for ps_mulsX and ps_sumX.