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: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: rth at twiddle dot net (Richard Henderson)
- Cc: gcc-patches at gcc dot gnu dot org, dave dot anglin at nrc-cnrc dot gc dot ca
- Date: Fri, 12 Nov 2010 19:23:57 -0500 (EST)
- Subject: Re: [patch 9/N][PA] convert to fma
> Untested.
Will test.
> ; fmpynfadd patterns
> -(define_insn ""
> +(define_insn "fnmadf4"
> [(set (match_operand:DF 0 "register_operand" "=f")
> - (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.
> [(set_attr "type" "fpmuldbl")
> (set_attr "length" "4")])
>
> -(define_insn ""
> +(define_insn "fnmasf4"
> [(set (match_operand:SF 0 "register_operand" "=f")
> - (minus:SF (match_operand:SF 1 "register_operand" "f")
> - (mult:SF (match_operand:SF 2 "register_operand" "f")
> - (match_operand:SF 3 "register_operand" "f"))))]
> + (fma:SF (neg:SF (match_operand:SF 1 "register_operand" "f"))
> + (match_operand:SF 2 "register_operand" "f")
> + (match_operand:SF 3 "register_operand" "f")))]
> "TARGET_PA_20 && ! TARGET_SOFT_FLOAT"
> - "fmpynfadd,sgl %2,%3,%1,%0"
> + "fmpynfadd,sgl %1,%2,%3,%0"
> [(set_attr "type" "fpmulsgl")
> (set_attr "length" "4")])
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)