This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 1/N][ia64] -mfused-madd cleanup


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]