This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch 9/N][PA] convert to fma
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>, gcc-patches at gcc dot gnu dot org, dave dot anglin at nrc-cnrc dot gc dot ca
- Date: Sat, 13 Nov 2010 16:10:55 -0800
- Subject: Re: [patch 9/N][PA] convert to fma
- References: <20101113002358.541EB4D30@hiauly1.hia.nrc.ca> <4CDF2798.5010007@twiddle.net>
On Sat, Nov 13, 2010 at 4:04 PM, Richard Henderson <rth@twiddle.net> wrote:
> On 11/12/2010 04:23 PM, John David Anglin wrote:
>>> - ? ?(minus:DF (match_operand:DF 1 "register_operand" "f")
>>> - ? ? ? ? ? ? ?(mult:DF (match_operand:DF 2 "register_operand" "f")
>>> - ? ? ? ? ? ? ? ? ? ? ? (match_operand:DF 3 "register_operand" "f"))))]
>>> + ? ?(fma:DF (neg:DF (match_operand:DF 1 "register_operand" "f"))
>>> + ? ? ? ? ? ?(match_operand:DF 2 "register_operand" "f")
>>> + ? ? ? ? ? ?(match_operand:DF 3 "register_operand" "f")))]
>>> ? ?"TARGET_PA_20 && ! TARGET_SOFT_FLOAT"
>>> - ?"fmpynfadd,dbl %2,%3,%1,%0"
>>> + ?"fmpynfadd,dbl %1,%2,%3,%0"
>>
>> I'm somewhat concerned about the above change. ?My reading of the fmpynfadd
>> instruction is that it negates the product. ?I don't think negating operand
>> 1 is equivalent when operand 2 is a NAN.
>
> Yes, -(a*b) = (-a)*b. ?I suppose you are correct that we could wind up with
> a difference between -QNaN (first case) and +QNaN (second case). ?But unlike
> caring for the sign of zero, there's nothing in gcc that seeks to preserve
> the sign of NaNs.
>
> I'll also say that this is the representation that we've been using for all
> of the other ports.
That is true. GCC doesn't even preserve kinds (Q vs S) of NaNs on
x86 with SSE FP math.
--
H.J.