Re: [PATCH, RFC] Proposed PowerPC IEEE 128-bit floating point changes

[Segher Boessenkool <segher@kernel.crashing.org>]

On Fri, Jul 21, 2017 at 03:17:57PM -0400, Michael Meissner wrote:
> The first change is to enable the C language to use _Float128 keyword (but not
> __float128) without having to use the -mfloat128 option on power7-power9
> systems.  My question is in the TR that introduced _Float128, is there any
> expectation that outside of the built-in functions we already provide, that we
> need to provide runtime functions?  Yes, glibc 2.26 will be coming along
> shortly, and it should provide most/all of the F128 functions, but distros
> won't pick this library up for some time.
> 
> I would like to enable it, but I want to avoid the problem that we have with
> __float128 in that once the keyword is supported, it is assumed everything is
> supported.  GCC and GLIBC run on different cycles (and different people work on
> it), and so you typically have to have GCC add support before GLIBC can use it.
> 
> We've discovered that boost and libstdc++ both assume the full library support
> exists if the __float128 keyword is used.  We will eventually need to tackle
> both of these libraries, but we need to the full GLIBC support (or libquadmath)
> to provide this functionality.

There isn't much we can do about libraries (or any other code) making
bad assumptions.  Reducing the pain is the best we can do.

> The third change is to add cpu names 'power7f', 'power8f', and 'power9f' that
> enable the appropriate power<n> architecture but also does a -mfloat128.  The
> motavation here is you cannot use either #pragma GCC target anywhere or the
> target attribute on the function with a target_clones attribute declaration.

Eww.  What a horrible hack.  Let's please find a sane way to handle this.

Float128 is not a feature only some power[789] variants have (and also it
could work on *all* targets), it also isn't some specific configuration
of the target (like LE is).


Segher