[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <EF5FA6C3467F85449672C3E735957B85015D9C3A72@BADAG02.ba.imgtec.org>
Date: Mon, 24 Jul 2017 13:36:05 +0000
From: Aleksandar Markovic <Aleksandar.Markovic@...tec.com>
To: James Hogan <James.Hogan@...tec.com>,
Aleksandar Markovic <aleksandar.markovic@...rk.com>
CC: "linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
Miodrag Dinic <Miodrag.Dinic@...tec.com>,
Goran Ferenc <Goran.Ferenc@...tec.com>,
"Douglas Leung" <Douglas.Leung@...tec.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Paul Burton <Paul.Burton@...tec.com>,
"Petar Jovanovic" <Petar.Jovanovic@...tec.com>,
Raghu Gandham <Raghu.Gandham@...tec.com>,
Ralf Baechle <ralf@...ux-mips.org>
Subject: RE: [PATCH v3 05/16] MIPS: math-emu: <MAX|MAXA|MIN|MINA>.<D|S>: Fix
quiet NaN propagation
Hi, James,
I appreciate your thorough and expeditious review.
>
> ________________________________________
> From: James Hogan
> Sent: Friday, July 21, 2017 7:45 AM
> To: Aleksandar Markovic
> Cc: linux-mips@...ux-mips.org; Aleksandar Markovic; Miodrag Dinic; Goran Ferenc; Douglas Leung; linux-kernel@...r.kernel.org; Paul Burton; Petar Jovanovic; Raghu Gandham; Ralf Baechle
> Subject: Re: [PATCH v3 05/16] MIPS: math-emu: <MAX|MAXA|MIN|MINA>.<D|S>: Fix quiet NaN propagation
>
> On Fri, Jul 21, 2017 at 04:09:03PM +0200, Aleksandar Markovic wrote:
> > From: Aleksandar Markovic <aleksandar.markovic@...tec.com>
> >
> > Fix the value returned by <MAX|MAXA|MIN|MINA>.<D|S>, if both inputs
> > are quiet NaNs. The specifications of <MAX|MAXA|MIN|MINA>.<D|S> state
> > that the returned value in such cases should be the quiet NaN
> > contained in register fs.
> >
> > The relevant example:
> >
> > MAX.S fd,fs,ft:
> > If fs contains qNaN1, and ft contains qNaN2, fd is going to contain
> > qNaN1 (without this patch, it used to contain qNaN2).
> >
>
> Consider adding:
>
> Fixes: a79f5f9ba508 ("MIPS: math-emu: Add support for the MIPS R6 MAX{, A} FPU instruction")
> Fixes: 4e9561b20e2f ("MIPS: math-emu: Add support for the MIPS R6 MIN{, A} FPU instruction")
>
Will add in v4 (for all MIN/MAX/MINA/MAXa patches).
> > Signed-off-by: Miodrag Dinic <miodrag.dinic@...tec.com>
> > Signed-off-by: Goran Ferenc <goran.ferenc@...tec.com>
> > Signed-off-by: Aleksandar Markovic <aleksandar.markovic@...tec.com>
>
> Consider adding:
>
> Cc: <stable@...r.kernel.org> # 4.3+
Will add on v4 (for all MIN/MAX/MINA/MAXA patches).
> > ---
> > arch/mips/math-emu/dp_fmax.c | 8 ++++++--
> > arch/mips/math-emu/dp_fmin.c | 8 ++++++--
> > arch/mips/math-emu/sp_fmax.c | 8 ++++++--
> > arch/mips/math-emu/sp_fmin.c | 8 ++++++--
> > 4 files changed, 24 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/mips/math-emu/dp_fmax.c b/arch/mips/math-emu/dp_fmax.c
> > index fd71b8d..567fc33 100644
> > --- a/arch/mips/math-emu/dp_fmax.c
> > +++ b/arch/mips/math-emu/dp_fmax.c
> > @@ -47,6 +47,9 @@ union ieee754dp ieee754dp_fmax(union ieee754dp x, union ieee754dp y)
> > case CLPAIR(IEEE754_CLASS_SNAN, IEEE754_CLASS_INF):
> > return ieee754dp_nanxcpt(x);
> >
> > + case CLPAIR(IEEE754_CLASS_QNAN, IEEE754_CLASS_QNAN):
> > + return x;
>
> couldn't the above...
>
> > +
> > /* numbers are preferred to NaNs */
> > case CLPAIR(IEEE754_CLASS_ZERO, IEEE754_CLASS_QNAN):
> > case CLPAIR(IEEE754_CLASS_NORM, IEEE754_CLASS_QNAN):
> > @@ -54,7 +57,6 @@ union ieee754dp ieee754dp_fmax(union ieee754dp x, union ieee754dp y)
>
> ... go somewhere around here and fall through to the existing return x
> case?
>
It could, but at the expense of code clarity and/or logical grouping of special cases,
which after this patch looks like:
. . .
|
case of both inputs qNaN
|
case of only x input qNaN
|
case of only y input qNaN
|
. . .
If you agree, I suggest keeping the code the same as currently proposed in
this patch, except that the following comments should be added in appropriate
places:
/*
* Quiet NaN handling
*/
/* The case of both inputs quiet NaNs */
. . .
/* The cases of exactly one input quiet NaN */
Unfortunately, the code segment for handling of sNaN and infinity inputs do
not follow the organization that I proposed. However, I think that my proposal
for case organization is the superior one - therefore I intend to keep it in v4,
unless you tell me not to do so.
Regards,
Aleksandar
Powered by blists - more mailing lists