target/hppa: Set Float3NaNPropRule explicitly

Set the Float3NaNPropRule explicitly for HPPA, and remove the
ifdef from pickNaNMulAdd().

HPPA is the only target that was using the default branch of the
ifdef ladder (other targets either do not use muladd or set
default_nan_mode), so we can remove the ifdef fallback entirely now
(allowing the "rule not set" case to fall into the default of the
switch statement and assert).

We add a TODO note that the HPPA rule is probably wrong; this is
not a behavioural change for this refactoring.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241202131347.498124-26-peter.maydell@linaro.org
This commit is contained in:
Peter Maydell 2024-12-11 15:30:59 +00:00
parent 703990100a
commit f8023791f2
2 changed files with 8 additions and 4 deletions

View File

@ -504,10 +504,6 @@ static int pickNaNMulAdd(FloatClass a_cls, FloatClass b_cls, FloatClass c_cls,
}
}
if (rule == float_3nan_prop_none) {
rule = float_3nan_prop_abc;
}
assert(rule != float_3nan_prop_none);
if (have_snan && (rule & R_3NAN_SNAN_MASK)) {
/* We have at least one SNaN input and should prefer it */

View File

@ -55,6 +55,14 @@ void HELPER(loaded_fr0)(CPUHPPAState *env)
* HPPA does note implement a CPU reset method at all...
*/
set_float_2nan_prop_rule(float_2nan_prop_s_ab, &env->fp_status);
/*
* TODO: The HPPA architecture reference only documents its NaN
* propagation rule for 2-operand operations. Testing on real hardware
* might be necessary to confirm whether this order for muladd is correct.
* Not preferring the SNaN is almost certainly incorrect as it diverges
* from the documented rules for 2-operand operations.
*/
set_float_3nan_prop_rule(float_3nan_prop_abc, &env->fp_status);
/* For inf * 0 + NaN, return the input NaN */
set_float_infzeronan_rule(float_infzeronan_dnan_never, &env->fp_status);
}