[PATCH] RFC for patch to add C99 fma/fmaf/fmal builtins
Michael Meissner
meissner@linux.vnet.ibm.com
Mon Oct 4 20:40:00 GMT 2010
I happen to reread parts of the C99 standard recently, and noticed the FMA
builtins. The current compiler defines fma{,f,l} builtins but does not provide
any code to expand the builtin.
The enclosed patch adds the basic FMA support to the compiler, and adds the
support to the powerpc backend. In doing a quick grep of the MD files, it
looks like the following ports may support a combined multiply/add operation
for floating point types:
arm
frv
i386
ia64
mips
mmix
pa
390
sh
spu
v850
xtensa
On the powerpc, I made the fma{,s} builtin always generate the the FMADD and
FMADDS instructions even if the user used -mno-fused-madd to suppress the
automatic merging of add/multiply operations, since that is in the intent of
the builtin to provide access to the merged instruction (on most hardware with
a FMA instruction, there is no merge step between the multiply and add, so the
result can be subtly different).
I will leave it to the port maintainers to implment FMA on their machines if
they wish or not if these patches go in.
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
I don't know what the few users of this builtin would expect as the default
behavior. I tend to think that #3 might be the best, in that often times with
-ffast-math, implementations that have a FMA instruciton would generate it.
A second issue is should we provide macros that say the port has an appropriate
FMA instruction. The C99 standard says that the following macros should be
defined in math.h if a fast fma implementation is provided:
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?
Thanks in advance.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner@linux.vnet.ibm.com
More information about the Gcc-patches
mailing list