On Mon, 2 Oct 2017, Michael Meissner wrote:
> > > But in any case, the new macro should be documented in cpp.texi alongside
> > > the existing __FP_FAST_FMA* macros (probably in the generic
> > > __FP_FAST_FMAF@var{n} and __FP_FAST_FMAF@var{n}X form).
> >
> > This patch adds support for adding the built-in __builtin_fmaf<N> and
> > __builtin_fmaf<N>x functions if the target machine supports an appropriate
> > fused multiply-add (FMA) instruction. This patch replaces the original
> > PowerPC
> > specific patch.
Certainly the <math.h> FP_FAST_FMA* macros are supposed to relate to
whether the public functions such as fmaf128 are fast rather than to
__builtin_* names.
I think there's a strong case that you should provide built-in functions
under the public names when defining __FP_FAST_FMA*. I.e., add a variant
of DEF_GCC_FLOATN_NX_BUILTINS that uses DEF_EXT_LIB_BUILTIN instead of
DEF_GCC_BUILTIN, and use that for the new built-in functions.
Then, the built-in functions, in whatever form they are provided, should
be documented in extend.texi, alongside the documentation of
__builtin_fabsf@var{n} etc. (with, of course, the caveats about
availability when appropriate instruction support isn't available - the
__builtin_fabsfN, __builtin_copysignfN functions are always inlined, the
fma ones aren't, and people may well lack C library support for the
underlying functions).
Given that, I don't think the warning about lack of instruction support is
appropriate; a call to __builtin_fmaf128, if the type is supported but
there is no corresponding instruction (on x86_64, say), would just fall
back to calling an external fmaf128 function (which in that case would
work with glibc 2.26 or later, though calls to fmaf64 etc. wouldn't), much
like any other such built-in function (we don't warn about e.g. calling
__builtin_clog10 on systems whose C library may not have clog10).
--
Joseph S. Myers
jos...@codesourcery.com
