This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch 1/N][ia64] -mfused-madd cleanup
- From: Richard Henderson <rth at redhat dot com>
- To: sje at cup dot hp dot com
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, joseph at codesourcery dot com, rguenther at suse dot de
- Date: Wed, 10 Nov 2010 15:50:55 -0800
- Subject: Re: [patch 1/N][ia64] -mfused-madd cleanup
- References: <4CDB246D.9060306@redhat.com> <1289431465.31009.107.camel@hpsje.cup.hp.com>
On 11/10/2010 03:24 PM, Steve Ellcey wrote:
> I am wondering if relying on FMA_EXPR will change the generated code for
> "float x = (float) a * b + c" where a, b, and c are doubles. Will we
> generate an fma followed by an fnorm truncation instead of just a fma.s.
>
> I'll put your patch in my nightly testing and see how it goes but other
> then the above question I think it looks good.
Yeah, I wasn't quite sure what to do with those right away.
I'm pretty sure that the actual fma.d instruction is
(fma:DF (reg:XF a) (reg:XF b) (reg:XF c))
by which I mean XFmode inputs to the infinite precision FMA
with a single rounding to DFmode at the end.
However, that's not something that the user can ever write.
The best we can do from source code is
(float_trunc:DF (fma:XF (reg:XF a) (reg:XF b) (reg:XF c))
meaning a rounding from infinite precision to XFmode (80 bits) followed
by a second rounding to DFmode (53 bits). We can obviously do this with
unsafe-math, but not otherwise.
OTOH, truncation to SFmode is, I think, safe all of the time since the
intermediate form of DF or XFmode has more than twice the precision of
the final result, and so the (lack of) double rounding ought not be visible.
Does that seem correct?
r~