| Message ID | 1302462766-8560-1-git-send-email-aurelien@aurel32.net |
|---|---|
| State | New |
| Headers | show |
On 10.04.2011, at 21:12, Aurelien Jarno wrote: > Now that PPC defaults to softfloat which always provides float128 > support, there is no need to keep two version of the code, depending if > float128 support is available or not. Suggested by Peter Maydell. > > Cc: Alexander Graf <agraf@suse.de> > Cc: Peter Maydell <peter.maydell@linaro.org> > Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Looks good to me, but I'd leave this to Peter's ack. Alex
On 10 April 2011 20:23, Alexander Graf <agraf@suse.de> wrote: > On 10.04.2011, at 21:12, Aurelien Jarno wrote: >> Now that PPC defaults to softfloat which always provides float128 >> support, there is no need to keep two version of the code, depending if >> float128 support is available or not. Suggested by Peter Maydell. > Looks good to me, but I'd leave this to Peter's ack. I think it's a sensible (and pretty straightforward) cleanup, yes. [my bias towards emulation-accuracy means I don't really see much place for softfloat-native in a tcg qemu target, so I have no compunction about dropping support for it. :-)] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> -- PMM
On 10.04.2011, at 22:08, Peter Maydell wrote: > On 10 April 2011 20:23, Alexander Graf <agraf@suse.de> wrote: >> On 10.04.2011, at 21:12, Aurelien Jarno wrote: >>> Now that PPC defaults to softfloat which always provides float128 >>> support, there is no need to keep two version of the code, depending if >>> float128 support is available or not. Suggested by Peter Maydell. > >> Looks good to me, but I'd leave this to Peter's ack. > > I think it's a sensible (and pretty straightforward) cleanup, yes. > [my bias towards emulation-accuracy means I don't really see > much place for softfloat-native in a tcg qemu target, so I have > no compunction about dropping support for it. :-)] I'm fairly indifferent. The easier we can make the targets, the better IMHO. Of course, if we're dog slow and accurate that doesn't help too much either :). Alex
On Sun, Apr 10, 2011 at 09:08:55PM +0100, Peter Maydell wrote: > On 10 April 2011 20:23, Alexander Graf <agraf@suse.de> wrote: > > On 10.04.2011, at 21:12, Aurelien Jarno wrote: > >> Now that PPC defaults to softfloat which always provides float128 > >> support, there is no need to keep two version of the code, depending if > >> float128 support is available or not. Suggested by Peter Maydell. > > > Looks good to me, but I'd leave this to Peter's ack. > > I think it's a sensible (and pretty straightforward) cleanup, yes. > [my bias towards emulation-accuracy means I don't really see > much place for softfloat-native in a tcg qemu target, so I have > no compunction about dropping support for it. :-)] It seems that also what people want. We regularly got complain about FP emulation precision (at least for the x86 target), but I don't remember someone complaining about the speed of the FP emulation. > Reviewed-by: Peter Maydell <peter.maydell@linaro.org> > Thanks for the review.
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c index c2a3212..4dae464 100644 --- a/target-ppc/op_helper.c +++ b/target-ppc/op_helper.c @@ -1287,7 +1287,6 @@ uint64_t helper_fmadd (uint64_t arg1, uint64_t arg2, uint64_t arg3) /* sNaN operation */ fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN); } -#ifdef FLOAT128 /* This is the way the PowerPC specification defines it */ float128 ft0_128, ft1_128; @@ -1303,10 +1302,6 @@ uint64_t helper_fmadd (uint64_t arg1, uint64_t arg2, uint64_t arg3) ft0_128 = float128_add(ft0_128, ft1_128, &env->fp_status); farg1.d = float128_to_float64(ft0_128, &env->fp_status); } -#else - /* This is OK on x86 hosts */ - farg1.d = (farg1.d * farg2.d) + farg3.d; -#endif } return farg1.ll; @@ -1332,7 +1327,6 @@ uint64_t helper_fmsub (uint64_t arg1, uint64_t arg2, uint64_t arg3) /* sNaN operation */ fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN); } -#ifdef FLOAT128 /* This is the way the PowerPC specification defines it */ float128 ft0_128, ft1_128; @@ -1348,10 +1342,6 @@ uint64_t helper_fmsub (uint64_t arg1, uint64_t arg2, uint64_t arg3) ft0_128 = float128_sub(ft0_128, ft1_128, &env->fp_status); farg1.d = float128_to_float64(ft0_128, &env->fp_status); } -#else - /* This is OK on x86 hosts */ - farg1.d = (farg1.d * farg2.d) - farg3.d; -#endif } return farg1.ll; } @@ -1376,7 +1366,6 @@ uint64_t helper_fnmadd (uint64_t arg1, uint64_t arg2, uint64_t arg3) /* sNaN operation */ fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN); } -#ifdef FLOAT128 /* This is the way the PowerPC specification defines it */ float128 ft0_128, ft1_128; @@ -1392,10 +1381,6 @@ uint64_t helper_fnmadd (uint64_t arg1, uint64_t arg2, uint64_t arg3) ft0_128 = float128_add(ft0_128, ft1_128, &env->fp_status); farg1.d = float128_to_float64(ft0_128, &env->fp_status); } -#else - /* This is OK on x86 hosts */ - farg1.d = (farg1.d * farg2.d) + farg3.d; -#endif if (likely(!float64_is_any_nan(farg1.d))) { farg1.d = float64_chs(farg1.d); } @@ -1423,7 +1408,6 @@ uint64_t helper_fnmsub (uint64_t arg1, uint64_t arg2, uint64_t arg3) /* sNaN operation */ fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN); } -#ifdef FLOAT128 /* This is the way the PowerPC specification defines it */ float128 ft0_128, ft1_128; @@ -1439,10 +1423,6 @@ uint64_t helper_fnmsub (uint64_t arg1, uint64_t arg2, uint64_t arg3) ft0_128 = float128_sub(ft0_128, ft1_128, &env->fp_status); farg1.d = float128_to_float64(ft0_128, &env->fp_status); } -#else - /* This is OK on x86 hosts */ - farg1.d = (farg1.d * farg2.d) - farg3.d; -#endif if (likely(!float64_is_any_nan(farg1.d))) { farg1.d = float64_chs(farg1.d); }
Now that PPC defaults to softfloat which always provides float128 support, there is no need to keep two version of the code, depending if float128 support is available or not. Suggested by Peter Maydell. Cc: Alexander Graf <agraf@suse.de> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> --- target-ppc/op_helper.c | 20 -------------------- 1 files changed, 0 insertions(+), 20 deletions(-)