aboutsummaryrefslogtreecommitdiff
path: root/fpu
AgeCommit message (Collapse)AuthorFilesLines
2025-07-10fpu: Process float_muladd_negate_result after roundingRichard Henderson2-14/+44
Changing the sign before rounding affects the correctness of the asymmetric rouding modes: float_round_up and float_round_down. Reported-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-02-25fpu: Build only oncePeter Maydell2-4/+1
Now we have removed all the target-specifics from the softfloat code, we can switch to building it once for the whole system rather than once per target. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250224111524.1101196-13-peter.maydell@linaro.org Message-id: 20250217125055.160887-11-peter.maydell@linaro.org
2025-02-25fpu: Don't compile-time disable hardfloat for PPC targetsPeter Maydell1-2/+0
We happen to know that for the PPC target the FP status flags (and in particular float_flag_inexact) will always be cleared before a floating point operation, and so can_use_fpu() will always return false. So we speed things up a little by forcing QEMU_NO_HARDFLOAT to true on that target. We would like to build softfloat once for all targets; that means removing target-specific ifdefs. Remove the check for TARGET_PPC; this won't change behaviour because can_use_fpu() will see that float_flag_inexact is clear and take the softfloat path anyway. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250224111524.1101196-12-peter.maydell@linaro.org Message-id: 20250217125055.160887-10-peter.maydell@linaro.org
2025-02-25fpu: Always decide snan_bit_is_one() at runtimePeter Maydell1-7/+0
Currently we have a compile-time shortcut where we return a hardcode value from snan_bit_is_one() on everything except MIPS, because we know that's the only target that needs to change status->no_signaling_nans at runtime. Remove the ifdef, so we always look at the status flag. This means we must update the two targets (HPPA and SH4) that were previously hardcoded to return true so that they set the status flag correctly. This has no behavioural change, but will be necessary if we want to build softfloat once for all targets. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250224111524.1101196-11-peter.maydell@linaro.org Message-id: 20250217125055.160887-9-peter.maydell@linaro.org
2025-02-25fpu: Always decide no_signaling_nans() at runtimePeter Maydell1-4/+0
Currently we have a compile-time shortcut where we return false from no_signaling_nans() on everything except Xtensa, because we know that's the only target that might ever set status->no_signaling_nans. Remove the ifdef, so we always look at the status flag; this has no behavioural change, but will be necessary if we want to build softfloat once for all targets. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250224111524.1101196-10-peter.maydell@linaro.org Message-id: 20250217125055.160887-8-peter.maydell@linaro.org
2025-02-25fpu: Move m68k_denormal fmt flag into floatx80_behaviourPeter Maydell2-8/+28
Currently we compile-time set an 'm68k_denormal' flag in the FloatFmt for floatx80 for m68k. This controls our handling of what the Intel documentation calls a "pseudo-denormal": a value where the exponent field is zero and the explicit integer bit is set. For x86, the x87 FPU is supposed to accept a pseudo-denormal as input, but never generate one on output. For m68k, these values are permitted on input and may be produced on output. Replace the flag in the FloatFmt with a flag indicating whether the float format has an explicit bit (which will be true for floatx80 for all targets, and false for every other float type). Then we can gate the handling of these pseudo-denormals on the setting of a floatx80_behaviour flag. As far as I can see from the code we don't actually handle the x86-mandated "accept on input but don't generate" behaviour, because the handling in partsN(canonicalize) looked at fmt->m68k_denormal. So I have added TODO comments to that effect. This commit doesn't change any behaviour for any target. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20250224111524.1101196-9-peter.maydell@linaro.org Message-id: 20250217125055.160887-7-peter.maydell@linaro.org
2025-02-25fpu: Pass float_status to floatx80_invalid_encoding()Peter Maydell1-1/+1
The definition of which floatx80 encodings are invalid is target-specific. Currently we handle this with an ifdef, but we would like to defer this decision to runtime. In preparation, pass a float_status argument to floatx80_invalid_encoding(). We will change the implementation from ifdef to looking at the status argument in the following commit. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20250224111524.1101196-7-peter.maydell@linaro.org
2025-02-25fpu: Make targets specify whether floatx80 Inf can have Int bit clearPeter Maydell1-10/+0
In Intel terminology, a floatx80 Infinity with the explicit integer bit clear is a "pseudo-infinity"; for x86 these are not valid infinity values. m68k is looser and does not care whether the Integer bit is set or clear in an infinity. Move this setting to runtime rather than using an ifdef in floatx80_is_infinity(). Since this was the last use of the floatx80_infinity global constant, we remove it and its definition here. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20250224111524.1101196-6-peter.maydell@linaro.org Message-id: 20250217125055.160887-5-peter.maydell@linaro.org
2025-02-25fpu: Make targets specify floatx80 default Inf at runtimePeter Maydell2-4/+13
Currently we hardcode at compile time whether the floatx80 default Infinity value has the explicit integer bit set or not (x86 sets it; m68k does not). To be able to compile softfloat once for all targets we'd like to move this setting to runtime. Define a new FloatX80Behaviour enum which is a set of flags that define the target's floatx80 handling. Initially we define just one flag, for whether the default Infinity has the Integer bit set or not, but we will expand this in future commits to cover the other floatx80 target specifics that we currently make compile-time settings. Define a new function floatx80_default_inf() which returns the appropriate default Infinity value of the given sign, and use it in the code that was previously directly using the compile-time constant floatx80_infinity_{low,high} values when packing an infinity into a floatx80. Since floatx80 is highly unlikely to be supported in any new architecture, and the existing code is generally written as "default to like x87, with an ifdef for m68k", we make the default value for the floatx80 behaviour flags be "what x87 does". This means we only need to change the m68k target to specify the behaviour flags. (Other users of floatx80 are the Arm NWFPE emulation, which is obsolete and probably not actually doing the right thing anyway, and the PPC xsrqpxp insn. Making the default be "like x87" avoids our needing to review and test for behaviour changes there.) We will clean up the remaining uses of the floatx80_infinity global constant in subsequent commits. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20250224111524.1101196-2-peter.maydell@linaro.org Message-id: 20250217125055.160887-2-peter.maydell@linaro.org
2025-02-11fpu: allow flushing of output denormals to be after roundingPeter Maydell1-6/+15
Currently we handle flushing of output denormals in uncanon_normal always before we deal with rounding. This works for architectures that detect tininess before rounding, but is usually not the right place when the architecture detects tininess after rounding. For example, for x86 the SDM states that the MXCSR FTZ control bit causes outputs to be flushed to zero "when it detects a floating-point underflow condition". This means that we mustn't flush to zero if the input is such that after rounding it is no longer tiny. At least one of our guest architectures does underflow detection after rounding but flushing of denormals before rounding (MIPS MSA); this means we need to have a config knob for this that is separate from our existing tininess_before_rounding setting. Add an ftz_detection flag. For consistency with tininess_before_rounding, we make it default to "detect ftz after rounding"; this means that we need to explicitly set the flag to "detect ftz before rounding" on every existing architecture that sets flush_to_zero, so that this commit has no behaviour change. (This means more code change here but for the long term a less confusing API.) For several architectures the current behaviour is either definitely or possibly wrong; annotate those with TODO comments. These architectures are definitely wrong (and should detect ftz after rounding): * x86 * Alpha For these architectures the spec is unclear: * MIPS (for non-MSA) * RX * SH4 PA-RISC makes ftz detection IMPDEF, but we aren't setting the "tininess before rounding" setting that we ought to. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2025-02-11fpu: Implement float_flag_input_denormal_usedPeter Maydell2-6/+100
For the x86 and the Arm FEAT_AFP semantics, we need to be able to tell the target code that the FPU operation has used an input denormal. Implement this; when it happens we set the new float_flag_denormal_input_used. Note that we only set this when an input denormal is actually used by the operation: if the operation results in Invalid Operation or Divide By Zero or the result is a NaN because some other input was a NaN then we never needed to look at the input denormal and do not set denormal_input_used. We mostly do not need to adjust the hardfloat codepaths to deal with this flag, because almost all hardfloat operations are already gated on the input not being a denormal, and will fall back to softfloat for a denormal input. The only exception is the comparison operations, where we need to add the check for input denormals, which must now fall back to softfloat where they did not before. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2025-02-11fpu: Add float_class_denormalPeter Maydell2-18/+54
Currently in softfloat we canonicalize input denormals and so the code that implements floating point operations does not need to care whether the input value was originally normal or denormal. However, both x86 and Arm FEAT_AFP require that an exception flag is set if: * an input is denormal * that input is not squashed to zero * that input is actually used in the calculation (e.g. we did not find the other input was a NaN) So we need to track that the input was a non-squashed denormal. To do this we add a new value to the FloatClass enum. In this commit we add the value and adjust the code everywhere that looks at FloatClass values so that the new float_class_denormal behaves identically to float_class_normal. We will add the code that does the "raise a new float exception flag if an input was an unsquashed denormal and we used it" in a subsequent commit. There should be no behavioural change in this commit. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2025-02-07target/i386: Do not raise Invalid for 0 * Inf + QNaNPeter Maydell1-2/+3
In commit 8adcff4ae7 ("fpu: handle raising Invalid for infzero in pick_nan_muladd") we changed the handling of 0 * Inf + QNaN to always raise the Invalid exception regardless of target architecture. (This was a change affecting hppa, i386, sh4 and tricore.) However, this was incorrect for i386, which documents in the SDM section 14.5.2 that for the 0 * Inf + NaN case that it will only raise the Invalid exception when the input is an SNaN. (This is permitted by the IEEE 754-2008 specification, which documents that whether we raise Invalid for 0 * Inf + QNaN is implementation defined.) Adjust the softfloat pick_nan_muladd code to allow the target to suppress the raising of Invalid for the inf * zero + NaN case (as an extra flag orthogonal to its choice for when to use the default NaN), and enable that for x86. We do not revert here the behaviour change for hppa, sh4 or tricore: * The sh4 manual is clear that it should signal Invalid * The tricore manual is a bit vague but doesn't say it shouldn't * The hppa manual doesn't talk about fused multiply-add corner cases at all Cc: qemu-stable@nongnu.org Fixes: 8adcff4ae7 (""fpu: handle raising Invalid for infzero in pick_nan_muladd") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/r/20250116112536.4117889-2-peter.maydell@linaro.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-01-28fpu: Rename float_flag_output_denormal to float_flag_output_denormal_flushedPeter Maydell2-2/+2
Our float_flag_output_denormal exception flag is set when the fpu code flushes an output denormal to zero. Rename it to float_flag_output_denormal_flushed: * this keeps it parallel with the flag for flushing input denormals, which we just renamed * it makes it clearer that it doesn't mean "set when the output is a denormal" Commit created with for f in `git grep -l float_flag_output_denormal`; do sed -i -e 's/float_flag_output_denormal/float_flag_output_denormal_flushed/' $f; done Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250124162836.2332150-21-peter.maydell@linaro.org
2025-01-28fpu: Rename float_flag_input_denormal to float_flag_input_denormal_flushedPeter Maydell2-3/+3
Our float_flag_input_denormal exception flag is set when the fpu code flushes an input denormal to zero. This is what many guest architectures (eg classic Arm behaviour) require, but it is not the only donarmal-related reason we might want to set an exception flag. The x86 behaviour (which we do not currently model correctly) wants to see an exception flag when a denormal input is *not* flushed to zero and is actually used in an arithmetic operation. Arm's FEAT_AFP also wants these semantics. Rename float_flag_input_denormal to float_flag_input_denormal_flushed to make it clearer when it is set and to allow us to add a new float_flag_input_denormal_used next to it for the x86/FEAT_AFP semantics. Commit created with for f in `git grep -l float_flag_input_denormal`; do sed -i -e 's/float_flag_input_denormal/float_flag_input_denormal_flushed/' $f; done and manual editing of softfloat-types.h and softfloat.c to clean up the indentation afterwards and to fix a comment which wasn't using the full name of the flag. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250124162836.2332150-20-peter.maydell@linaro.org
2024-12-24softfloat: Add float_muladd_suppress_add_product_zeroRichard Henderson2-1/+6
Certain Hexagon instructions suppress changes to the result when the product of fma() is a true zero. Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-12-24softfloat: Add float_round_nearest_even_maxRichard Henderson1-0/+3
This rounding mode is used by Hexagon. Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-12-24softfloat: Remove float_muladd_halve_resultRichard Henderson2-10/+0
All uses have been convered to float*_muladd_scalbn. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-12-24softfloat: Add float{16,32,64}_muladd_scalbnRichard Henderson2-27/+38
We currently have a flag, float_muladd_halve_result, to scale the result by 2**-1. Extend this to handle arbitrary scaling. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-12-11softfloat: Replace WHICH with RET in parts_pick_nanRichard Henderson1-15/+13
Replace the "index" selecting between A and B with a result variable of the proper type. This improves clarity within the function. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241203203949.483774-12-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11softfloat: Sink frac_cmp in parts_pick_nan until neededRichard Henderson1-10/+9
Move the fractional comparison to the end of the float_2nan_prop_x87 case. This is not required for any other 2nan propagation rule. Reorganize the x87 case itself to break out of the switch when the fractional comparison is not required. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20241203203949.483774-11-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11softfloat: Share code between parts_pick_nan casesRichard Henderson1-20/+12
Remember if there was an SNaN, and use that to simplify float_2nan_prop_s_{ab,ba} to only the snan component. Then, fall through to the corresponding float_2nan_prop_{ab,ba} case to handle any remaining nans, which must be quiet. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20241203203949.483774-10-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11softfloat: Inline pickNaNRichard Henderson2-104/+72
Inline pickNaN into its only caller. This makes one assert redundant with the immediately preceding IF. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241203203949.483774-9-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11softfloat: Use parts_pick_nan in propagateFloatx80NaNRichard Henderson1-39/+6
Unpacking and repacking the parts may be slightly more work than we did before, but we get to reuse more code. For a code path handling exceptional values, this is an improvement. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241203203949.483774-8-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11softfloat: Move propagateFloatx80NaN to softfloat.cRichard Henderson2-52/+52
This function is part of the public interface and is not "specialized" to any target in any way. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20241203203949.483774-7-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11softfloat: Pad array size in pick_nan_muladdRichard Henderson1-1/+1
While all indices into val[] should be in [0-2], the mask applied is two bits. To help static analysis see there is no possibility of read beyond the end of the array, pad the array to 4 entries, with the final being (implicitly) NULL. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241203203949.483774-6-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11softfloat: Remove which from parts_pick_nan_muladdRichard Henderson1-22/+10
Assign the pointer return value to 'a' directly, rather than going through an intermediary index. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241203203949.483774-5-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11softfloat: Use goto for default nan case in pick_nan_muladdRichard Henderson1-10/+10
Remove "3" as a special case for which and simply branch to return the desired value. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241203203949.483774-4-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11softfloat: Inline pickNaNMulAddRichard Henderson2-55/+40
Inline pickNaNMulAdd into its only caller. This makes one assert redundant with the immediately preceding IF. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241203203949.483774-3-richard.henderson@linaro.org [PMM: keep comment from old code in new location] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-12-11fpu: Remove default handling for dnan_patternPeter Maydell1-14/+0
Now that all our targets have bene converted to explicitly specify their pattern for the default NaN value we can remove the remaining fallback code in parts64_default_nan(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-55-peter.maydell@linaro.org
2024-12-11target/hexagon: Set default NaN pattern explicitlyPeter Maydell1-5/+0
Set the default NaN pattern explicitly for hexagon. Remove the ifdef from parts64_default_nan(); the only remaining unconverted targets all use the default case. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-52-peter.maydell@linaro.org
2024-12-11target/sparc: Set default NaN pattern explicitlyPeter Maydell1-4/+1
Set the default NaN pattern explicitly for SPARC, and remove the ifdef from parts64_default_nan. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-50-peter.maydell@linaro.org
2024-12-11target/m68k: Set default NaN pattern explicitlyPeter Maydell1-1/+1
Set the default NaN pattern explicitly for m68k. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-43-peter.maydell@linaro.org
2024-12-11target/hppa: Set default NaN pattern explicitlyPeter Maydell1-3/+0
Set the default NaN pattern explicitly, and remove the ifdef from parts64_default_nan(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-39-peter.maydell@linaro.org
2024-12-11target/i386: Set default NaN pattern explicitlyPeter Maydell1-3/+0
Set the default NaN pattern explicitly, and remove the ifdef from parts64_default_nan(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-38-peter.maydell@linaro.org
2024-12-11target/microblaze: Set default NaN pattern explicitlyPeter Maydell1-2/+1
Set the default NaN pattern explicitly, and remove the ifdef from parts64_default_nan(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-37-peter.maydell@linaro.org
2024-12-11fpu: Allow runtime choice of default NaN valuePeter Maydell1-21/+32
Currently we hardcode the default NaN value in parts64_default_nan() using a compile-time ifdef ladder. This is awkward for two cases: * for single-QEMU-binary we can't hard-code target-specifics like this * for Arm FEAT_AFP the default NaN value depends on FPCR.AH (specifically the sign bit is different) Add a field to float_status to specify the default NaN value; fall back to the old ifdef behaviour if these are not set. The default NaN value is specified by setting a uint8_t to a pattern corresponding to the sign and upper fraction parts of the NaN; the lower bits of the fraction are set from bit 0 of the pattern. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-35-peter.maydell@linaro.org
2024-12-11softfloat: Create floatx80 default NaN from parts64_default_nanPeter Maydell1-10/+10
We create our 128-bit default NaN by calling parts64_default_nan() and then adjusting the result. We can do the same trick for creating the floatx80 default NaN, which lets us drop a target ifdef. floatx80 is used only by: i386 m68k arm nwfpe old floating-point emulation emulation support (which is essentially dead, especially the parts involving floatx80) PPC (only in the xsrqpxp instruction, which just rounds an input value by converting to floatx80 and back, so will never generate the default NaN) The floatx80 default NaN as currently implemented is: m68k: sign = 0, exp = 1...1, int = 1, frac = 1....1 i386: sign = 1, exp = 1...1, int = 1, frac = 10...0 These are the same as the parts64_default_nan for these architectures. This is technically a possible behaviour change for arm linux-user nwfpe emulation emulation, because the default NaN will now have the sign bit clear. But we were already generating a different floatx80 default NaN from the real kernel emulation we are supposedly following, which appears to use an all-bits-1 value: https://elixir.bootlin.com/linux/v6.12/source/arch/arm/nwfpe/softfloat-specialize#L267 This won't affect the only "real" use of the nwfpe emulation, which is ancient binaries that used it as part of the old floating point calling convention; that only uses loads and stores of 32 and 64 bit floats, not any of the floatx80 behaviour the original hardware had. We also get the nwfpe float64 default NaN value wrong: https://elixir.bootlin.com/linux/v6.12/source/arch/arm/nwfpe/softfloat-specialize#L166 so if we ever cared about this obscure corner the right fix would be to correct that so nwfpe used its own default-NaN setting rather than the Arm VFP one. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-29-peter.maydell@linaro.org
2024-12-11target/hppa: Set Float3NaNPropRule explicitlyPeter Maydell1-4/+0
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
2024-12-11target/xtensa: Set Float3NaNPropRule explicitlyPeter Maydell1-8/+0
Set the Float3NaNPropRule explicitly for xtensa, and remove the ifdef from pickNaNMulAdd(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-24-peter.maydell@linaro.org
2024-12-11target/mips: Set Float3NaNPropRule explicitlyPeter Maydell1-7/+1
Set the Float3NaNPropRule explicitly for Arm, and remove the ifdef from pickNaNMulAdd(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-23-peter.maydell@linaro.org
2024-12-11target/sparc: Set Float3NaNPropRule explicitlyPeter Maydell1-2/+0
Set the Float3NaNPropRule explicitly for SPARC, and remove the ifdef from pickNaNMulAdd(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-22-peter.maydell@linaro.org
2024-12-11target/s390x: Set Float3NaNPropRule explicitlyPeter Maydell1-2/+0
Set the Float3NaNPropRule explicitly for s390x, and remove the ifdef from pickNaNMulAdd(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-21-peter.maydell@linaro.org
2024-12-11target/ppc: Set Float3NaNPropRule explicitlyPeter Maydell1-6/+0
Set the Float3NaNPropRule explicitly for PPC, and remove the ifdef from pickNaNMulAdd(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-20-peter.maydell@linaro.org
2024-12-11target/loongarch: Set Float3NaNPropRule explicitlyPeter Maydell1-2/+0
Set the Float3NaNPropRule explicitly for loongarch, and remove the ifdef from pickNaNMulAdd(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-19-peter.maydell@linaro.org
2024-12-11target/arm: Set Float3NaNPropRule explicitlyPeter Maydell1-7/+1
Set the Float3NaNPropRule explicitly for Arm, and remove the ifdef from pickNaNMulAdd(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-18-peter.maydell@linaro.org
2024-12-11softfloat: Allow runtime choice of NaN propagation for muladdPeter Maydell1-125/+40
IEEE 758 does not define a fixed rule for which NaN to pick as the result if both operands of a 3-operand fused multiply-add operation are NaNs. As a result different architectures have ended up with different rules for propagating NaNs. QEMU currently hardcodes the NaN propagation logic into the binary because pickNaNMulAdd() has an ifdef ladder for different targets. We want to make the propagation rule instead be selectable at runtime, because: * this will let us have multiple targets in one QEMU binary * the Arm FEAT_AFP architectural feature includes letting the guest select a NaN propagation rule at runtime In this commit we add an enum for the propagation rule, the field in float_status, and the corresponding getters and setters. We change pickNaNMulAdd to honour this, but because all targets still leave this field at its default 0 value, the fallback logic will pick the rule type with the old ifdef ladder. It's valid not to set a propagation rule if default_nan_mode is enabled, because in that case there's no need to pick a NaN; all the callers of pickNaNMulAdd() catch this case and skip calling it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-16-peter.maydell@linaro.org
2024-12-11softfloat: Pass have_snan to pickNaNMulAddPeter Maydell2-3/+4
The new implementation of pickNaNMulAdd() will find it convenient to know whether at least one of the three arguments to the muladd was a signaling NaN. We already calculate that in the caller, so pass it in as a new bool have_snan. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-15-peter.maydell@linaro.org
2024-12-11target/hppa: Set FloatInfZeroNaNRule explicitlyPeter Maydell1-12/+1
Set the FloatInfZeroNaNRule explicitly for the HPPA target, so we can remove the ifdef from pickNaNMulAdd(). As this is the last target to be converted to explicitly setting the rule, we can remove the fallback code in pickNaNMulAdd() entirely. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-14-peter.maydell@linaro.org
2024-12-11target/loongarch: Set FloatInfZeroNaNRule explicitlyPeter Maydell1-6/+1
Set the FloatInfZeroNaNRule explicitly for the loongarch target. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-13-peter.maydell@linaro.org