This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, MIPS] Enable fp-contract on MIPS and update -mfused-madd
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Steve Ellcey <sellcey at imgtec dot com>, gcc-patches at gcc dot gnu dot org, Catherine Moore <clm at codesourcery dot com>, Matthew Fortune <matthew dot fortune at imgtec dot com>
- Date: Mon, 15 Jun 2015 22:37:18 +0100 (BST)
- Subject: Re: [Patch, MIPS] Enable fp-contract on MIPS and update -mfused-madd
- Authentication-results: sourceware.org; auth=none
- References: <4c25620c-546c-40ae-b330-3652fe25f791 at BAMAIL02 dot ba dot imgtec dot org> <alpine dot DEB dot 2 dot 10 dot 1506112002380 dot 15628 at digraph dot polyomino dot org dot uk> <alpine dot LFD dot 2 dot 11 dot 1506152042580 dot 5418 at eddie dot linux-mips dot org> <alpine dot DEB dot 2 dot 10 dot 1506152047390 dot 9772 at digraph dot polyomino dot org dot uk>
On Mon, 15 Jun 2015, Joseph Myers wrote:
> > operands negated. That negation, implemented with the IEEE Std 754-2008
> > `negate' operation that you referred to, by definition is required to
> > operate on the sign of its operand in a specific way even if the operand
> > is a qNaN.
> >
> > So for example `fmsM4', that is specified at the RTL level as (fma:M OP1
> > OP2 (neg:M OP3)) will not produce the correct result with the fused
> > version of the MIPS MSUB.fmt instruction in the case where OP1 and OP2 are
> > numeric data patterns and OP3 is a qNaN data pattern that has its sign bit
> > clear. As specified by IEEE Std 754-2008 the (neg:M OP3) operation is
> > required to invert the sign bit of the qNaN data pattern in calculating
> > TMP3, and then the (fma:M OP1 OP2 TMP3) operation is required to pass the
> > TMP3 qNaN data pattern unchanged in calculating the final result.
>
> It is only required (well, recommended) to pass the *payload*. The sign
> bit is not part of the payload. "For all other operations, this standard
> does not specify the sign bit of a NaN result, even when there is only one
> input NaN, or when the NaN is produced from an invalid operation.".
However elsewhere: "For an operation with quiet NaN inputs, other than
maximum and minimum operations, if a floating-point result is to be
delivered the result shall be a quiet NaN which should be one of the input
NaNs.".
I think such a wording makes it clear that the input NaN bit pattern is
propagated with no change whatsoever and I can't immediately infer if, for
the purpose of standard interpretation, the clause you've quoted extends
one that I have or whether one I've quoted narrows one that you have.
Maybe this is a mistake/inconsistency in the standard.
Of course you're right these are recommendations only ("should" vs
"shall"), but I think we might want to have/keep a mode where IEEE Std 754
recommendations are strictly followed (where hardware permits).
Maciej