[PATCH] RFC for patch to add C99 fma/fmaf/fmal builtins

Richard Henderson rth@redhat.com
Mon Oct 4 21:08:00 GMT 2010


On 10/04/2010 01:40 PM, Michael Meissner wrote:
> My question is what should we do if the port has no FMA instruction?
> 
>    1)	Always call fma external (current behavior)
>    2)	Expand to (operand[0] * operand[1]) + operand[2] always
>    3)	Expand to (operand[0] * operand[1]) + operand[2] if -ffast-math

(2) is clearly wrong, (3) I really don't have an opinion about.

I seem to recall that double-rounding is ok as long as the intermediate
step contains > 2N bits.  Which implies that for IEEE single (23 bits)
we can generically implement it with IEEE double (53 bits > 46):

  result = (float)((double)op0 * (double)op1) + (double)op2);

Whether that is worthwhile of course depends on the availability of
the appropriate instructions in hardware.  So for instance it's not
likely to be helpful to implement fma with IEEE quad (113 bits > 106),
since the later is not actually available in hardware on most (any?)
platforms.

I might just stay with (1) for the moment.

> 	FP_FAST_FMA
> 	FP_FAST_FMAF
> 	FP_FAST_FMAL
> 
> I would imagine that we should provide __FAST_FMA__, __FAST_FMAF__, and
> __FAST_FMAL__ macros that the library math.h file could test and define
> FP_FAST_FMA* if desired.  Do people have an opinion on this?

Seems reasonable.


r~



More information about the Gcc-patches mailing list