From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YL8JE-0000Pk-RH for qemu-devel@nongnu.org; Tue, 10 Feb 2015 05:44:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YL8JB-0002WZ-F6 for qemu-devel@nongnu.org; Tue, 10 Feb 2015 05:44:48 -0500 Received: from mailapp01.imgtec.com ([195.59.15.196]:15892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YL8JB-0002Vz-9n for qemu-devel@nongnu.org; Tue, 10 Feb 2015 05:44:45 -0500 Message-ID: <54D9E116.9060201@imgtec.com> Date: Tue, 10 Feb 2015 10:44:38 +0000 From: Leon Alrae MIME-Version: 1.0 References: <54D8EA12.3030004@imgtec.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 7/7] target-mips: Add IEEE 754-2008 features support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Maciej W. Rozycki" Cc: qemu-devel@nongnu.org, Aurelien Jarno , Thomas Schwinge On 09/02/2015 20:55, Maciej W. Rozycki wrote: >>> +uint32_t helper_float_chs_s(CPUMIPSState *env, uint32_t fst0) >>> +{ >>> + uint32_t fst1; >>> + >>> + fst1 = float32_sub(0, fst0, &env->active_fpu.fp_status); >>> + update_fcr31(env, GETPC()); >>> + return fst1; >>> +} >> >> I think there is one case where helper_float_chs_{d,s,ps} are not >> correct -- when we have zero. In this case in subFloat32Sigs() we call: >> >> return packFloat32(status->float_rounding_mode == float_round_down, 0, 0); >> >> and the packFloat32() definition: >> >> static inline float32 packFloat32(flag zSign, int_fast16_t zExp, >> uint32_t zSig) >> { >> >> return make_float32( >> ( ( (uint32_t) zSign )<<31 ) + ( ( (uint32_t) zExp )<<23 ) + >> zSig); >> >> } >> >> Which means that the sign may not get changed, whereas I believe NEG.fmt >> is supposed to reverse the sign bit of positive/negative zero regardless >> of rounding mode. > > Good catch, I missed this corner case, thanks! Another corner case is > then helper_float_abs_{d,s,ps} with -0 as input and `float_round_down' > being the current rounding mode. > > These cases could be addressed by either replacing subtraction from 0.0 > with multiplication by -1.0, or by tweaking the rounding mode as needed > temporarily. Given that the computational cost of multiplication is > uncertain and likely higher or at best the same as the cost of addition or > subtraction, I'd be leaning towards the latter solution. My first thought was to treat zero in NEG.fmt as a special case and use float32_chs() for it. But tweaking the rounding mode temporarily probably is better as we will get consistent behaviour for zero as well as input denormals which are squashed in float32_sub() when flush_inputs_to_zero flag is set (actually I'm not sure if legacy fp instructions should flush input denormals, but according to the spec this is implementation dependent so I won't worry about this). Leon