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: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
