Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753724AbdGXMpu convert rfc822-to-8bit (ORCPT ); Mon, 24 Jul 2017 08:45:50 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:45839 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751632AbdGXMpk (ORCPT ); Mon, 24 Jul 2017 08:45:40 -0400 From: Aleksandar Markovic To: James Hogan , Aleksandar Markovic CC: "linux-mips@linux-mips.org" , Miodrag Dinic , Goran Ferenc , "Douglas Leung" , "linux-kernel@vger.kernel.org" , Paul Burton , "Petar Jovanovic" , Raghu Gandham , Ralf Baechle Subject: RE: [PATCH v3 11/16] MIPS: math-emu: .: Fix NaN propagation Thread-Topic: [PATCH v3 11/16] MIPS: math-emu: .: Fix NaN propagation Thread-Index: AQHTAit/SvXBAKyY40KYXcnAouqzcaJjPv0A//+d87M= Date: Mon, 24 Jul 2017 12:45:33 +0000 Message-ID: References: <1500646206-2436-1-git-send-email-aleksandar.markovic@rt-rk.com> <1500646206-2436-12-git-send-email-aleksandar.markovic@rt-rk.com>,<20170724102412.GP6973@jhogan-linux.le.imgtec.org> In-Reply-To: <20170724102412.GP6973@jhogan-linux.le.imgtec.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.117.201.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4069 Lines: 87 > _______________________________________ > From: James Hogan > Sent: Monday, July 24, 2017 3:24 AM > To: Aleksandar Markovic > Cc: linux-mips@linux-mips.org; Aleksandar Markovic; Miodrag Dinic; Goran Ferenc; Douglas Leung; linux-> kernel@vger.kernel.org; Paul Burton; Petar Jovanovic; Raghu Gandham; Ralf Baechle > Subject: Re: [PATCH v3 11/16] MIPS: math-emu: .: Fix NaN propagation > > On Fri, Jul 21, 2017 at 04:09:09PM +0200, Aleksandar Markovic wrote: > > From: Aleksandar Markovic > > > > Fix the cases of . when any of three inputs is any > > NaN. Correct behavior of . fd, fs, ft is following: > > > > - if any of inputs is sNaN, return a sNaN using following rules: if > > only one input is sNaN, return that one; if more than one input is > > sNaN, order of precedence for return value is fd, fs, ft > > - if no input is sNaN, but at least one of inputs is qNaN, return a > > qNaN using following rules: if only one input is qNaN, return that > > one; if more than one input is qNaN, order of precedence for > > return value is fd, fs, ft > > > > The previous code contained handling of some above cases, but not all. > > Also, such handling was scattered into various cases of > > "switch (CLPAIR(xc, yc))" statement and elsewhere. With this patch, > > this logic is placed in one place, and "switch (CLPAIR(xc, yc))" is > > significantly simplified. > > > > The relevant example: > > > > MADDF.S fd,fs,ft: > > If fs contains qNaN1, ft contains qNaN2, and fd contains qNaN3, fd > > is going to contain qNaN3 (without this patch, it used to contain > > qNaN1). > > > > Fixes: e24c3bec3e8e ("MIPS: math-emu: Add support for the MIPS R6 MADDF FPU instruction") > Fixes: 83d43305a1df ("MIPS: math-emu: Add support for the MIPS R6 MSUBF FPU instruction") > In v4, I will add these lines to commit messages of all MADDF/MSUBF patches from this series. > > Signed-off-by: Miodrag Dinic > > Signed-off-by: Goran Ferenc > > Signed-off-by: Aleksandar Markovic > > > If backported, I suspect commits: > > 6162051e87f6 ("MIPS: math-emu: Unify ieee754sp_m{add,sub}f") > > and > > d728f6709bcc ("MIPS: math-emu: Unify ieee754dp_m{add,sub}f") > > in 4.7 will require manual backporting between 4.3 and 4.7 (due to > > separation of maddf/msubf before that point), so I suppose tagging > > stable 4.7+ and backporting is best (assuming you consider this fix > > worth backporting). I am going to tag all MADDF/MSUBF patches "stable 4.7+" and all MIN/MAX/MINA/MAXA patches "stable 4.3+" in v4. > > --- > > arch/mips/math-emu/dp_maddf.c | 71 ++++++++++++++----------------------------- > > arch/mips/math-emu/sp_maddf.c | 69 ++++++++++++++--------------------------- > > 2 files changed, 46 insertions(+), 94 deletions(-) > ... > > + /* handle the cases when at least one of x, y or z is a NaN */ > > + if (((xc == IEEE754_CLASS_SNAN) || (xc == IEEE754_CLASS_QNAN)) || > > + ((yc == IEEE754_CLASS_SNAN) || (yc == IEEE754_CLASS_QNAN)) || > > + ((zc == IEEE754_CLASS_SNAN) || (zc == IEEE754_CLASS_QNAN))) { > > This condition basically covers all of the cases below. Any particular > reason not to skip it ... > > + /* order of precedence is z, x, y */ > > + if (zc == IEEE754_CLASS_SNAN) > > + return ieee754dp_nanxcpt(z); > > + if (xc == IEEE754_CLASS_SNAN) > > + return ieee754dp_nanxcpt(x); > > + if (yc == IEEE754_CLASS_SNAN) > > + return ieee754dp_nanxcpt(y); > > + if (zc == IEEE754_CLASS_QNAN) > > + return z; > > + if (xc == IEEE754_CLASS_QNAN) > > + return x; > > return y; > > ... and make this return conditional on (yc == IEEE754_CLASS_QNAN)? You are right. I am going to reorganize the code as you suggested in v4. Regards, Aleksandar