aboutsummaryrefslogtreecommitdiff
path: root/fpu
AgeCommit message (Collapse)AuthorFilesLines
2024-12-11target/x86: Set FloatInfZeroNaNRule explicitlyPeter Maydell1-1/+1
Set the FloatInfZeroNaNRule explicitly for the x86 target. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-12-peter.maydell@linaro.org
2024-12-11target/xtensa: Set FloatInfZeroNaNRule explicitlyPeter Maydell1-1/+1
Set the FloatInfZeroNaNRule explicitly for the xtensa target, so we can 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-11-peter.maydell@linaro.org
2024-12-11target/sparc: Set FloatInfZeroNaNRule explicitlyPeter Maydell1-2/+1
Set the FloatInfZeroNaNRule explicitly for the SPARC target, so we can 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-10-peter.maydell@linaro.org
2024-12-11target/mips: Set FloatInfZeroNaNRule explicitlyPeter Maydell1-15/+1
Set the FloatInfZeroNaNRule explicitly for the MIPS target, so we can 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-9-peter.maydell@linaro.org
2024-12-11target/ppc: Set FloatInfZeroNaNRule explicitlyPeter Maydell1-6/+1
Set the FloatInfZeroNaNRule explicitly for the PPC target, so we can 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-8-peter.maydell@linaro.org
2024-12-11target/s390: Set FloatInfZeroNaNRule explicitlyPeter Maydell1-2/+0
Set the FloatInfZeroNaNRule explicitly for s390, so we can 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-7-peter.maydell@linaro.org
2024-12-11target/arm: Set FloatInfZeroNaNRule explicitlyPeter Maydell1-7/+1
Set the FloatInfZeroNaNRule explicitly for the Arm target, so we can 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-6-peter.maydell@linaro.org
2024-12-11softfloat: Allow runtime choice of inf * 0 + NaN resultPeter Maydell1-30/+61
IEEE 758 does not define a fixed rule for what NaN to return in the case of a fused multiply-add of inf * 0 + NaN. Different architectures thus do different things: * some return the default NaN * some return the input NaN * Arm returns the default NaN if the input NaN is quiet, and the input NaN if it is signalling We want to make this logic be runtime selected rather than hardcoded into the binary, 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. Note that four architectures both use the muladd softfloat functions and did not have a branch of the ifdef ladder to specify their behaviour (and so were ending up with the "default" case, probably wrongly): i386, HPPA, SH4 and Tricore. SH4 and Tricore both set default_nan_mode, and so will never get into pickNaNMulAdd(). For HPPA and i386 we retain the same behaviour as the old default-case, which is to not ever return the default NaN. This might not be correct but it is not a behaviour change. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-4-peter.maydell@linaro.org
2024-12-11fpu: Check for default_nan_mode before calling pickNaNMulAddPeter Maydell2-4/+13
If the target sets default_nan_mode then we're always going to return the default NaN, and pickNaNMulAdd() no longer has any side effects. For consistency with pickNaN(), check for default_nan_mode before calling pickNaNMulAdd(). When we convert pickNaNMulAdd() to allow runtime selection of the NaN propagation rule, this means we won't have to make the targets which use default_nan_mode also set a propagation rule. Since RiscV always uses default_nan_mode, this allows us to remove its ifdef case from pickNaNMulAdd(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-3-peter.maydell@linaro.org
2024-12-11fpu: handle raising Invalid for infzero in pick_nan_muladdPeter Maydell2-34/+8
For IEEE fused multiply-add, the (0 * inf) + NaN case should raise Invalid for the multiplication of 0 by infinity. Currently we handle this in the per-architecture ifdef ladder in pickNaNMulAdd(). However, since this isn't really architecture specific we can hoist it up to the generic code. For the cases where the infzero test in pickNaNMulAdd was returning 2, we can delete the check entirely and allow the code to fall into the normal pick-a-NaN handling, because this will return 2 anyway (input 'c' being the only NaN in this case). For the cases where infzero was returning 3 to indicate "return the default NaN", we must retain that "return 3". For Arm, this looks like it might be a behaviour change because we used to set float_flag_invalid | float_flag_invalid_imz only if C is a quiet NaN. However, it is not, because Arm target code never looks at float_flag_invalid_imz, and for the (0 * inf) + SNaN case we already raised float_flag_invalid via the "abc_mask & float_cmask_snan" check in pick_nan_muladd. For any target architecture using the "default implementation" at the bottom of the ifdef, this is a behaviour change but will be fixing a bug (where we failed to raise the Invalid exception for (0 * inf + QNaN). The architectures using the default case are: * hppa * i386 * sh4 * tricore The x86, Tricore and SH4 CPU architecture manuals are clear that this should have raised Invalid; HPPA is a bit vaguer but still seems clear enough. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241202131347.498124-2-peter.maydell@linaro.org
2024-11-18target/s390x: Fix the floating-point multiply-and-add NaN rulesIlya Leoshkevich1-0/+19
Order the helper arguments to match the Principles of Operation. Implement the "Results: MULTIPLY AND ADD" table in pickNaNMulAdd(). Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-ID: <20241023000147.34035-2-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-11-05softfloat: Remove fallback rule from pickNaN()Peter Maydell1-20/+3
Now that all targets have been converted to explicitly set a NaN propagation rule, we can remove the set of target ifdefs (which now list every target) and clean up the references to fallback behaviour for float_2nan_prop_none. The "default" case in the switch will catch any remaining places where status->float_2nan_prop_rule was not set by the target. 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: 20241025141254.2141506-22-peter.maydell@linaro.org
2024-11-05target/rx: Explicitly set 2-NaN propagation rulePeter Maydell1-1/+2
Set the NaN propagation rule explicitly for the float_status word used in the rx target. This not the architecturally correct behaviour, but since this is a no-behaviour-change patch, we leave a TODO note to that effect. 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: 20241025141254.2141506-21-peter.maydell@linaro.org
2024-11-05target/openrisc: Explicitly set 2-NaN propagation rulePeter Maydell1-1/+1
Set the NaN propagation rule explicitly for the float_status word used in the openrisc target. 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: 20241025141254.2141506-20-peter.maydell@linaro.org
2024-11-05target/microblaze: Explicitly set 2-NaN propagation rulePeter Maydell1-1/+2
Set the NaN propagation rule explicitly for the float_status word used in the microblaze target. This is probably not the architecturally correct behaviour, but since this is a no-behaviour-change patch, we leave a TODO note to that effect. 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: 20241025141254.2141506-19-peter.maydell@linaro.org
2024-11-05target/alpha: Explicitly set 2-NaN propagation rulePeter Maydell1-1/+1
Set the NaN propagation rule explicitly for the float_status word used in this target. This is a no-behaviour-change commit, so we retain the existing behaviour of x87-style pick-largest-significand NaN propagation. This is however not the architecturally correct handling, so we leave a TODO note to that effect. We also leave a TODO note pointing out that all this code in the cpu initfn (including the existing setting up of env->flags and the FPCR) should be in a currently non-existent CPU reset function. 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: 20241025141254.2141506-17-peter.maydell@linaro.org
2024-11-05target/i386: Set 2-NaN propagation rule explicitlyPeter Maydell1-1/+2
Set the NaN propagation rule explicitly for the float_status words used in the x86 target. This is a no-behaviour-change commit, so we retain the existing behaviour of using the x87-style "prefer QNaN over SNaN, then prefer the NaN with the larger significand" for MMX and SSE. This is however not the documented hardware behaviour, so we leave a TODO note about what we should be doing instead. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-16-peter.maydell@linaro.org
2024-11-05target/xtensa: Explicitly set 2-NaN propagation rulePeter Maydell1-11/+1
Set the NaN propagation rule explicitly in xtensa_use_first_nan(). (When we convert the softfloat pickNaNMulAdd routine to also select a NaN propagation rule at runtime, we will be able to remove the use_first_nan flag because the propagation rules will handle everything.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-15-peter.maydell@linaro.org
2024-11-05target/sparc: Explicitly set 2-NaN propagation rulePeter Maydell1-4/+2
Set the NaN propagation rule explicitly in the float_status words we use. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-13-peter.maydell@linaro.org
2024-11-05target/m68k: Explicitly set 2-NaN propagation rulePeter Maydell1-18/+1
Explicitly set the 2-NaN propagation rule on env->fp_status and on the temporary fp_status that we use in frem (since we pass that to a division operation function). 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>
2024-11-05target/ppc: Explicitly set 2-NaN propagation rulePeter Maydell1-8/+2
Set the 2-NaN propagation rule explicitly in env->fp_status and env->vec_status. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-9-peter.maydell@linaro.org
2024-11-05target/s390x: Explicitly set 2-NaN propagation rulePeter Maydell1-3/+2
Set the 2-NaN propagation rule explicitly in env->fpu_status. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-8-peter.maydell@linaro.org
2024-11-05target/hppa: Explicitly set 2-NaN propagation rulePeter Maydell1-2/+2
Set the 2-NaN propagation rule explicitly in env->fp_status. Really we only need to do this at CPU reset (after reset has zeroed out most of the CPU state struct, which typically includes fp_status fields). However target/hppa does not currently implement CPU reset at all, so leave a TODO comment to note that this could be moved if we ever do implement reset. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-7-peter.maydell@linaro.org
2024-11-05target/loongarch: Explicitly set 2-NaN propagation rulePeter Maydell1-3/+3
Set the 2-NaN propagation rule explicitly in the float_status word we use. (There are a couple of places in fpu_helper.c where we create a dummy float_status word with "float_status *s = { };", but these are only used for calling float*_is_quiet_nan() so it doesn't matter that we don't set a 2-NaN propagation rule there.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-6-peter.maydell@linaro.org
2024-11-05target/mips: Explicitly set 2-NaN propagation rulePeter Maydell1-16/+2
Set the 2-NaN propagation rule explicitly in the float_status words we use. For active_fpu.fp_status, we do this in a new fp_reset() function which mirrors the existing msa_reset() function in doing "first call restore to set the fp status parts that depend on CPU state, then set the fp status parts that are constant". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241025141254.2141506-5-peter.maydell@linaro.org
2024-11-05target/arm: Explicitly set 2-NaN propagation rulePeter Maydell1-11/+2
Set the 2-NaN propagation rule explicitly in the float_status words we use. We wrap this plus the pre-existing setting of the tininess-before-rounding flag in a new function arm_set_default_fp_behaviours() to avoid repetition, since we have a lot of float_status words at this point. The situation with FPA11 emulation in linux-user is a little odd, and arguably "correct" behaviour there would be to exactly match a real Linux kernel's FPA11 emulation. However FPA11 emulation is essentially dead at this point and so it seems better to continue with QEMU's current behaviour and leave a comment describing the situation. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-4-peter.maydell@linaro.org
2024-11-05softfloat: Allow 2-operand NaN propagation rule to be set at runtimePeter Maydell1-95/+130
IEEE 758 does not define a fixed rule for which NaN to pick as the result if both operands of a 2-operand 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 pickNaN() 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 * x86 specifies different propagation rules for x87 FPU ops and for SSE ops, and specifying the rule in the float_status would let us emulate this, instead of wrongly using the x87 rules everywhere In this commit we add an enum for the propagation rule, the field in float_status, and the corresponding getters and setters. We change pickNaN 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 pickNaN() catch this case and skip calling it. So we can already assert that we don't get into the "no rule defined" codepath for our four targets which always set default_nan_mode: Hexagon, RiscV, SH4 and Tricore, and for the one target which does not have FP at all: avr. These targets will not need to be updated to call set_float_2nan_prop_rule(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-2-peter.maydell@linaro.org
2024-09-24fpu: remove break after g_assert_not_reached()Pierrick Bouvier1-2/+0
This patch is part of a series that moves towards a consistent use of g_assert_not_reached() rather than an ad hoc mix of different assertion mechanisms. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-ID: <20240919044641.386068-24-pierrick.bouvier@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-09-13target/cris: Remove the deprecated CRIS targetPhilippe Mathieu-Daudé1-2/+2
The CRIS target is deprecated since v9.0 (commit c7bbef40234 "docs: mark CRIS support as deprecated"). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Message-ID: <20240904143603.52934-14-philmd@linaro.org>
2024-06-05target/sparc: Implement FMAf extensionRichard Henderson1-0/+31
Rearrange PDIST so that do_dddd is general purpose and may be re-used for FMADDd etc. Add pickNaN and pickNaNMulAdd. Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-04-24target/nios2: Remove the deprecated Nios II targetPhilippe Mathieu-Daudé1-1/+1
The Nios II target is deprecated since v8.2 in commit 9997771bc1 ("target/nios2: Deprecate the Nios II architecture"). Remove: - Buildsys / CI infra - User emulation - System emulation (10m50-ghrd & nios2-generic-nommu machines) - Tests Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Marek Vasut <marex@denx.de> Message-Id: <20240327144806.11319-3-philmd@linaro.org>
2024-04-01fpu/softfloat: Remove mention of TILE-Gx targetPhilippe Mathieu-Daudé1-1/+1
TILE-Gx has been removed during the v6.0 release (see commit 2cc1a90166 "Remove deprecated target tilegx"), no need to mention it in the list of "supported targets". Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-16fpu: Handle m68k extended precision denormals properlyRichard Henderson2-4/+12
Motorola treats denormals with explicit integer bit set as having unbiased exponent 0, unlike Intel which treats it as having unbiased exponent 1 (more like all other IEEE formats that have no explicit integer bit). Add a flag on FloatFmt to differentiate the behaviour. Reported-by: Keith Packard <keithp@keithp.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-09-16fpu: Add conversions between bfloat16 and [u]int8LIU Zhiwei1-0/+58
We missed these functions when upstreaming the bfloat16 support. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-Id: <20230531065458.2082-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-07-01fpu: Add float64_to_int{32,64}_moduloRichard Henderson2-0/+109
Add versions of float64_to_int* which do not saturate the result. Reviewed-by: Christoph Muellner <christoph.muellner@vrull.eu> Tested-by: Christoph Muellner <christoph.muellner@vrull.eu> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20230527141910.1885950-2-richard.henderson@linaro.org>
2023-06-26softfloat: use QEMU_FLATTEN to avoid mistaken isra inliningAlex Bennée1-11/+11
Balton discovered that asserts for the extract/deposit calls had a significant impact on a lame benchmark on qemu-ppc. Replicating with: ./qemu-ppc64 ~/lsrc/tests/lame.git-svn/builds/ppc64/frontend/lame \ -h pts-trondheim-3.wav pts-trondheim-3.mp3 showed up the pack/unpack routines not eliding the assert checks as it should have done causing them to prominently figure in the profile:  11.44%  qemu-ppc64  qemu-ppc64               [.] unpack_raw64.isra.0  11.03%  qemu-ppc64  qemu-ppc64               [.] parts64_uncanon_normal   8.26%  qemu-ppc64  qemu-ppc64               [.] helper_compute_fprf_float64   6.75%  qemu-ppc64  qemu-ppc64               [.] do_float_check_status   5.34%  qemu-ppc64  qemu-ppc64               [.] parts64_muladd   4.75%  qemu-ppc64  qemu-ppc64               [.] pack_raw64.isra.0   4.38%  qemu-ppc64  qemu-ppc64               [.] parts64_canonicalize   3.62%  qemu-ppc64  qemu-ppc64               [.] float64r32_round_pack_canonical After this patch the same test runs 31 seconds faster with a profile where the generated code dominates more: + 14.12% 0.00% qemu-ppc64 [unknown] [.] 0x0000004000619420 + 13.30% 0.00% qemu-ppc64 [unknown] [.] 0x0000004000616850 + 12.58% 12.19% qemu-ppc64 qemu-ppc64 [.] parts64_uncanon_normal + 10.62% 0.00% qemu-ppc64 [unknown] [.] 0x000000400061bf70 + 9.91% 9.73% qemu-ppc64 qemu-ppc64 [.] helper_compute_fprf_float64 + 7.84% 7.82% qemu-ppc64 qemu-ppc64 [.] do_float_check_status + 6.47% 5.78% qemu-ppc64 qemu-ppc64 [.] parts64_canonicalize.constprop.0 + 6.46% 0.00% qemu-ppc64 [unknown] [.] 0x0000004000620130 + 6.42% 0.00% qemu-ppc64 [unknown] [.] 0x0000004000619400 + 6.17% 6.04% qemu-ppc64 qemu-ppc64 [.] parts64_muladd + 5.85% 0.00% qemu-ppc64 [unknown] [.] 0x00000040006167e0 + 5.74% 0.00% qemu-ppc64 [unknown] [.] 0x0000b693fcffffd3 + 5.45% 4.78% qemu-ppc64 qemu-ppc64 [.] float64r32_round_pack_canonical Suggested-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <ec9cfe5a-d5f2-466d-34dc-c35817e7e010@linaro.org> [AJB: Patchified rth's suggestion] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20230523131107.3680641-1-alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-05-05softfloat: Fix the incorrect computation in float32_exp2Shivaprasad G Bhat1-1/+1
The float32_exp2 function is computing wrong exponent of 2. For example, with the following set of values {0.1, 2.0, 2.0, -1.0}, the expected output would be {1.071773, 4.000000, 4.000000, 0.500000}. Instead, the function is computing {1.119102, 3.382044, 3.382044, -0.191022} Looking at the code, the float32_exp2() attempts to do this 2 3 4 5 n x x x x x x x e = 1 + --- + --- + --- + --- + --- + ... + --- + ... 1! 2! 3! 4! 5! n! But because of the typo it ends up doing x x x x x x x e = 1 + --- + --- + --- + --- + --- + ... + --- + ... 1! 2! 3! 4! 5! n! This is because instead of the xnp which holds the numerator, parts_muladd is using the xp which is just 'x'. Commit '572c4d862ff2' refactored this function, and mistakenly used xp instead of xnp. Cc: qemu-stable@nongnu.org Fixes: 572c4d862ff2 "softfloat: Convert float32_exp2 to FloatParts" Partially-Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1623 Reported-By: Luca Barbato (https://gitlab.com/lu-zero) Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Message-Id: <168304110865.537992.13059030916325018670.stgit@localhost.localdomain> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-10-17softfloat: logB(0) should raise divideByZero exceptionSong Gao1-0/+1
logB(0) should raise divideByZero exception from IEEE 754-2008 spec 7.3 Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220930024510.800005-4-gaosong@loongson.cn>
2022-08-31fpu: Add rebias bool, value and operationLucas Mateus Castro (alqotel)2-2/+21
Added the possibility of recalculating a result if it overflows or underflows, if the result overflow and the rebias bool is true then the intermediate result should have 3/4 of the total range subtracted from the exponent. The same for underflow but it should be added to the exponent of the intermediate number instead. Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220805141522.412864-2-lucas.araujo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-07-20Merge tag 'pull-request-2022-07-20' of https://gitlab.com/thuth/qemu into ↵Peter Maydell1-2/+2
staging * Fixes for s390x floating point vector instructions # gpg: Signature made Wed 20 Jul 2022 08:14:50 BST # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'pull-request-2022-07-20' of https://gitlab.com/thuth/qemu: tests/tcg/s390x: test signed vfmin/vfmax target/s390x: fix NaN propagation rules target/s390x: fix handling of zeroes in vfmin/vfmax Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # fpu/softfloat-specialize.c.inc
2022-07-19fpu/softfloat: Add LoongArch specializations for pickNaN*Song Gao1-1/+25
The muladd (inf,zero,nan) case sets InvalidOp and returns the input value 'c', and prefer sNaN over qNaN, in c,a,b order. Binary operations prefer sNaN over qNaN and a,b order. Signed-off-by: Song Gao <gaosong@loongson.cn> Message-Id: <20220716085426.3098060-3-gaosong@loongson.cn> [rth: Add specialization for pickNaN] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-07-19target/s390x: fix NaN propagation rulesIlya Leoshkevich1-1/+2
s390x has the same NaN propagation rules as ARM, and not as x86. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20220713182612.3780050-3-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-04-26softfloat: Use FloatRelation for fracN_cmpRichard Henderson1-5/+7
Since the caller, partsN_compare, is now exclusively using FloatRelation, it's clearer to use it here too. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20220401132240.79730-4-richard.henderson@linaro.org>
2022-04-26softfloat: Use FloatRelation within partsN_compareRichard Henderson1-4/+7
As the return type is FloatRelation, it's clearer to use the type for 'cmp' within the function. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20220401132240.79730-3-richard.henderson@linaro.org>
2022-04-26softfloat: Fix declaration of partsN_compareRichard Henderson1-4/+4
The declaration used 'int', while the definition used 'FloatRelation'. This should have resulted in a compiler error, but mysteriously didn't. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20220401132240.79730-2-richard.henderson@linaro.org>
2022-04-20softfloat: add float128_to_int128Matheus Ferst1-0/+64
Implements float128_to_int128 based on parts_float_to_int logic. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220330175932.6995-7-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-20softfloat: add float128_to_uint128Matheus Ferst1-0/+65
Implements float128_to_uint128 based on parts_float_to_uint logic. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220330175932.6995-6-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-20softfloat: add int128_to_float128Matheus Ferst1-0/+29
Based on parts_sint_to_float, implements int128_to_float128 to convert a signed 128-bit value received through an Int128 argument. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Message-Id: <20220330175932.6995-5-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-20softfloat: add uint128_to_float128Matheus Ferst1-0/+25
Based on parts_uint_to_float, implements uint128_to_float128 to convert an unsigned 128-bit value received through an Int128 argument. Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220330175932.6995-4-matheus.ferst@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2021-12-17softfloat: Add float64r32 arithmetic routinesRichard Henderson1-0/+110
These variants take a float64 as input, compute the result to infinite precision (as we do with FloatParts), round the result to the precision and dynamic range of float32, and then return the result in the format of float64. This is the operation PowerPC requires for its float32 operations. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20211119160502.17432-28-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
generated by cgit v1.1 at 2025-09-25 01:44:17 +0000