This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH #2], Define __FP_FAST_FMAF128 on PowerPC ISA 3.0
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, Richard Biener <rguenther at suse dot de>, Jakub Jelinek <jakub at redhat dot com>, Jason Merrill <jason at redhat dot com>, Richard Earnshaw <richard dot earnshaw at arm dot com>, "David S. Miller" <davem at redhat dot com>, Bernd Schmidt <bernds_cb1 at t-online dot de>, Ian Lance Taylor <ian at airs dot com>, Jim Wilson <wilson at tuliptree dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, David Edelsohn <dje dot gcc at gmail dot com>, Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- Date: Tue, 3 Oct 2017 01:19:16 +0000
- Subject: Re: [PATCH #2], Define __FP_FAST_FMAF128 on PowerPC ISA 3.0
- Authentication-results: sourceware.org; auth=none
- References: <20170927221818.GA20589@ibm-tiger.the-meissners.org> <alpine.DEB.2.20.1709280035390.32152@digraph.polyomino.org.uk> <20171002235100.GA15723@ibm-tiger.the-meissners.org> <20171002235250.GA21210@ibm-tiger.the-meissners.org>
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
joseph@codesourcery.com