From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCW9K-0002kK-Ke for qemu-devel@nongnu.org; Wed, 20 Apr 2011 08:04:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCW9J-0007To-BU for qemu-devel@nongnu.org; Wed, 20 Apr 2011 08:04:50 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:33676) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCW9J-0007Te-9H for qemu-devel@nongnu.org; Wed, 20 Apr 2011 08:04:49 -0400 Received: by vws17 with SMTP id 17so574673vws.4 for ; Wed, 20 Apr 2011 05:04:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1303299154-14373-1-git-send-email-aurelien@aurel32.net> References: <1303299154-14373-1-git-send-email-aurelien@aurel32.net> Date: Wed, 20 Apr 2011 13:04:48 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 1/3] target-ppc: simplify NaN propagation for vector functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: qemu-devel@nongnu.org, Alexander Graf On 20 April 2011 12:32, Aurelien Jarno wrote: > Commit e024e881bb1a8b5085026589360d26ed97acdd64 provided a pickNaN() > function for PowerPC, implementing the correct NaN propagation rules. > Therefore there is no need to test the operands manually, we can rely > on the softfloat code to do that. > > Cc: Alexander Graf > Signed-off-by: Aurelien Jarno > --- > =C2=A0target-ppc/op_helper.c | =C2=A0 26 +++++++------------------- > =C2=A01 files changed, 7 insertions(+), 19 deletions(-) > > Note: Unfortunately the current propagation rules implemented in > softfloat only concerns 2 operands operations, so we have to keep > HANDLE_NAN3 for now. These first two patches remove all of the uses of HANDLE_NAN1 and HANDLE_NAN2, so we can just delete those macro definitions, right? You could clean up DO_HANDLE_NAN a little: #define DO_HANDLE_NAN(result, x) \ if (float32_is_any_nan(x)) { \ result =3D float32_maybe_silence_nan(x); \ } else On a slight tangent: I need to add ARM support for fused multiply-accumulate (vfma,vfms), so perhaps in the long run it would be better to make them softfloat primitives? (they are after all in the new IEEE spec, so they're in softfloat's domain in some sense.) That would move the 'propagate one of 3 NaNs' logic into softfloat. (I suspect that implementing fused-mac by doing intermediate results mas float64 will set the Inexact bit for some cases where the hardware will not, but I haven't thought too deeply about it yet.) -- PMM