This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH], Add support for __builtin_{sqrt,fma}f128 on PowerPC ISA 3.0
- From: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Segher Boessenkool <segher at kernel dot crashing dot org>, David Edelsohn <dje dot gcc at gmail dot com>, Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- Date: Thu, 14 Sep 2017 15:02:41 -0400
- Subject: Re: [PATCH], Add support for __builtin_{sqrt,fma}f128 on PowerPC ISA 3.0
- Authentication-results: sourceware.org; auth=none
- References: <20170913214600.GA24598@ibm-tiger.the-meissners.org> <alpine.DEB.2.20.1709132239500.28319@digraph.polyomino.org.uk>
On Wed, Sep 13, 2017 at 10:49:43PM +0000, Joseph Myers wrote:
> On Wed, 13 Sep 2017, Michael Meissner wrote:
>
> > This patch adds support on PowerPC ISA 3.0 for the built-in function
> > __builtin_sqrtf128 generating the XSSQRTQP hardware square root instruction and
> > the built-in function __builtin_fmaf128 generating XSMADDQP, XSMSUBQP,
> > XSNMADDQP, and XSNMSUBQP fused multiply-add instructions.
>
> Is there a reason for these to be architecture-specific rather than
> generic everywhere _Float128 is supported? (With the fmaf128 / sqrtf128
> names available as well as the __builtin_* variants of those.)
I wanted to get in the PowerPC stuff ASAP, so the library people can start
using it.
I do think for at least some of the built-ins (sqrt, fma, lrint, etc.) it makes
sense, and at some point I was going to look at it.
In the grand scheme of things, it is only a temporary measure, and the real end
goal is to enable switching long double to be float128. However, that will
take multiple releases to get there.
> Full support for _FloatN/_FloatNx variants of all the existing built-in
> functions might be complicated, and run into potential issues with startup
> cost of creating large numbers of extra built-in functions (it's
> desirable, but possibly hard, which is why I excluded it from the initial
> _FloatN / _FloatNx support patches). But adding just these two functions
> to builtins.def and making them fold / expand appropriately ought to be
> much simpler. (I realise sqrt goes through internal-fn.def and
> DEF_INTERNAL_FLT_FN expects a particular set of functions for standard
> types, so maybe some duplication would be involved to get the built-in
> function expanded appropriately, i.e. using an insn pattern or a call to
> an external sqrtf128 function according to whether such an insn pattern is
> available. fma ought not to involve much more than adding an extra case
> where CASE_FLT_FN (BUILT_IN_FMA) is used.)
Yeah, but I wanted to get the easy stuff in there right now before looking at
the machine independent support.
> > While I was at it, I changed the documentation so that it no longer documents
> > the 'q' built-in functions (to mirror libquadmath) but instead just documented
> > the 'f128' functions that matches glibc 2.26 and the technical report that
> > added the _FloatF128 date.
>
> Those *f128 built-in functions (inf / huge_val / nan / nans / fabs /
> copysign) are not target-specific; they exist for all _FloatN / _FloatNx
> types for all targets with such types. So it doesn't seem appropriate to
> document them in a target-specific section of the manual, beyond a brief
> cross-reference to the documentation of the functions as
> target-independent.
Right now we just document a few of the 'q' functions that were added before
you added the f128 versions. I was trying to harmonize things. Originally, I
was going to make both __builtin_sqrtq and __builtin_sqrtf128, but Segher and
David didn't want that.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797