Re: RFC Migrating PowerPC to IEEE 128-bit Floating Point

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Tue, 2016-03-08 at 01:31 +0000, Joseph Myers wrote:
> On Mon, 7 Mar 2016, Paul E. Murphy wrote:
> 
> > On 10/13/2015 06:11 PM, Joseph Myers wrote:
> > 
> > > Now, here are some examples of issues to consider in the design and 
> > > consensus-building process.  Where I suggest answers here, I am *not* 
> > > asserting that only a particular answer is acceptable - what is or is not 
> > > required is determined by the community through a consensus process, and 
> > > generally these are cases where if making such changes myself I'd still 
> > > want to allow for the community to reach consensus first rather than 
> > > acting as libm maintainer to treat something as having consensus in the 
> > > absence of discussion.  It's only the two principles I stated in 
> > > <https://sourceware.org/ml/libc-alpha/2015-09/msg00751.html> about ABI 
> > > compatibility requirements that I'm confident asserting as definite 
> > > requirements here, that are well-enough established no further discussion 
> > > of them is required to understand their application to this case.
> > 
> > If I understand you, for a PPC ABI to support __float128, the minimum
> > compiler version for building glibc would need to be raised to guarantee
> > the availability of the new ABI?
> 
Sorry for my delay in responding to this thread, i was waiting for
clarity on the GCC 6 side.

> Yes - that is, raised for all PPC platforms for which these functions are 
> added to glibc - having a well defined ABI for a given library in a given 
> glibc version on a given platform is a pretty fundamental principle.  And 
> since certain required features (complex float128 support and a few 
> built-in functions) didn't get into GCC 6, that means that the minimum 
> version would be at least GCC 7 (as I noted in 
> <https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02222.html>).
> 
> [There are ways of avoiding needing the complex arithmetic libgcc support 
> - not much in libm uses it - but because of the other dependencies that 
> will require GCC 7, and because you still need the compiler side of 
> complex support, I don't think that would really help.]
> 
Waiting for GCC7 is not acceptable for starting this work. We believe we
have the agreements in place to complete the required __float128
enablement in GCC6.1. This will deliver parity with the existing x86_64
__float128 support, Including complex.



> This does not of course prevent much of the preparatory work being done in 
> the context of supporting such functions on x86_64, say (where the 
> compiler support already exists in all compilers supported for building 
> glibc) - the vast bulk of that work would be necessary to support a fourth 
> floating-point format on any architecture at all, and I wouldn't be 
> surprised if it's a 50-patch or more series of complicated changes 
> building on each other (and each of which takes several attempts to get 
> right and to reach consensus).
> 
As stated above we plan to complete the __float128 enablement for
PowerPC by GCC6.1.

We have requirements and deadlines that do  allow for the delay of a
whole year. If we can't get consensus from the community on reasonable
accommodations on this timeline we will br forced to look at
alternatives.

We would like to spend the development effort for GLIBC-2.24 preparing
the GLIBC infrastructure for adding additional floating types to libm
(as implied and required by  TS18661).

This would include extending the configure and Makefiles as needed to
add another directory under ieee754 contains implementations with new
type related suffixes (other then '', 'f', and 'l').

This would include:
      * getting agreement on additional controlling  Makefile variables
        similar to 'long-m-routines' for f128 and f64x. This will be
        used to extend and control ./math/Makefile.
      * getting agreement on additional controlling macros similar to
        __LONG_DOUBLE_MATH and __NO_LONG_DOUBLE_MATH for f128 and f64x.
        This will be used to extend and control math.h
      * getting agreement on how we use __STDC_WANT_IEC_60559_BFP_EXT__
        within math.h complex.h and tgmath.h. This is not necessarily to
        complete all the requirements of TS18661 but to prepare the way
        to that work.
      * getting agreement on directory naming and file structure.
      * getting agreement on the best way to share implementation across
        functionally equivalent but linguistically different types.

The infrastructure above should remain latent (inactive) until
explicitly enabled for a specific platform. This should to similar to
current mechanism used for long double based on platform specific
Implies files naming additional implementation directories, containing
Makefile fragments that enable the base ./math/Makefile machinery. 

This should have minimal (preferably no) impact on any other platform.

With this infrastructure in place we then use the GLIBC-2.25 development
period for submitting the libm functional implementations. 


> (Given such preparation, simply adding powerpc64 to the architectures 
> building float128 support would be a fairly small change, while supporting 
> it as an alternative long double format - thus supporting three different 
> long double formats - would be a much trickier change or series of 
> changes; Jakub's original support for multiple long double formats took 
> years to get in, and as I noted earlier in this discussion it still missed 
> several functions that ought to have variants for different long double 
> formats; getting all the cases right is hard.  Furthermore, the design of 
> how that handles different printf variants with a TLS __no_long_double 
> variable is not AS-safe when different parts of a program use different 
> long double formats, and given the view in bug 16060 that at least dprintf 
> should be AS-safe, and given that glibc reviewers pay much more attention 
> to such issues than they did ten years ago, repeating that design might 
> well fail to obtain consensus.)
> 
> (Given some of the preparatory work, it should be much easier to update 
> libquadmath from glibc, and so get current code to users via GCC before 
> the glibc ABI can be updated, than it is at present.)
> 
> > > * We need to agree that the prior rejection of __float128 support in 
> > > <https://sourceware.org/ml/libc-alpha/2004-03/msg00326.html> and 
> > > <https://sourceware.org/ml/libc-alpha/2004-05/msg00055.html> no longer 
> > > stands, in the light of the existence of standard C bindings in TS 
> > > 18661-3.  I don't think there should be any controversy about superseding 
> > > such an old decision, but it should still be clear that we are doing so.
> > 
> > Those old patches appear to attempt to basically merge libquadmath into
> > glibc (or do I have it wrong, and that was the genesis of quadmath?). Are
> 
> These old patches long predate libquadmath (or at least its inclusion in 
> GCC).
> 
> > you suggesting we should be figuring out a plan to support _Float128 as
> > defined by TS 18661?
> 
> I think any new APIs for float128 support should follow TS 18661-3, yes 
> (this doesn't mean the whole of TS 18661-3 needs supporting, where the 
> corresponding float / double / long double functions aren't in glibc).  
> It does need extending for at least some floating-point functions in glibc 
> with no float128 analogues in TS 18661-3 - see my previous points about 
> the various classes of such functions that need considering individually 
> to decide whether float128 versions should be added.
> 
> Now, following TS 18661-3 means there is *nothing* in those 2004 changes 
> that is actually wanted in glibc - because they deal with I/O, and TS 
> 18661 does not add any printf/scanf formats for new floating point types; 
> rather, it uses strto* and strfrom* functions (so one or more of the 
> preparatory patches in the 50-patch series would be adding the strfrom* 
> functions from TS 18661-1 for the existing floating-point types, with 
> thorough testcases written in a type-generic way, in preparation for later 
> adding them for float128).  (And while sysdeps directory structures are 
> one of the more tricky design questions, I don't think those old changes 
> have anything useful regarding strto* either.)
> 
> There are certainly questions to work out regarding what extra compiler 
> support might be desirable in conjunction with float128 support in glibc - 
> but for now I think it's desirable to be able to build such support in 
> glibc (for x86_64 etc.) with existing compilers that support the 
> __float128 name but not _Float128 (and __attribute__ ((__mode__ 
> ((__TC__)))) for complex _Float128, etc.), although maybe with an 
> expectation to phase out that support in time to simplify the code 
> eventually (e.g. doing compiler support in parallel with the glibc 
> support).  __float128 would become a built-in typedef for _Float128 when 
> _Float128 is supported in the compiler.
> 
It is my assumption that we will be working on PPC64LE and ABI V2 to
start. There is no need to wait for GCC-7.

X86_64 has different set of issues (80-bit long double) and large set
of ./sysdeps/ platform specific implementations that we don't have the
skills to address.

I sure that the Intel team can address specifics of float128 when and if
they decide to. They will benefit from our early work on common Makefile
machinery.

> > > * We need to agree on the appropriateness of APIs from TS 18661 - that is, 
> > > to get consensus on a whole set of APIs being appropriate for glibc, so 
> > > that doesn't need redebating every time an individual new API is proposed.  
> > > The APIs from parts 1, 3 and 4, excluding those relating to decimal 
> > > floating point, seem a reasonable set to consider in such a discussion 
> > > (with a clear expectation that such APIs could then be added piecemeal, 
> > > with individual patches still needing consensus on the merits of the 
> > > implementation).  (If controversial, the minimal set for present purposes 
> > > would be the _Float128 APIs from part 3 that correspond to APIs already 
> > > present in glibc for other floating-point types, but I hope it would be 
> > > possible to obtain consensus on a wider set of APIs.)
> 
> Regarding such consensus, see the discussion I started at 
> <https://sourceware.org/ml/libc-alpha/2015-11/msg00162.html> in an attempt 
> to get consensus in advance of any implementation.  There wasn't 
> opposition to the appropriateness of those APIs, but not many people 
> commented either.
> 
> Note that consensus in principle for various new APIs does not mean 
> consensus for completely arbitrary subsets thereof; there should be some 
> coherence to the sets added.  For example, one thing to consider would be 
> whether TS 18661-3 functions should first be added in cases where they 
> alias existing functions (including for _Float32, _Float64, _Float32x etc. 
> - and including _Float128 on architectures where it aliases the existing 
> long double), with support for them as separate being later in the patch 
> series.
> 
> > > * We need to agree on rules for ABIs corresponding to such APIs.  My 
> > > suggestion is: where an API meets the ISO C rules for being usable without 
> > > including a header, the function needs an exported symbol with the same 
> > > name (for example, if we support sinf128 on a platform where long double 
> > > is binary128, there does actually need to be a sinf128 exported symbol, 
> > > not just a header redirecting calls to use sinl).  But if it doesn't meet 
> > > such rules, the number of exported symbols should be kept to a minimum 
> > > (for example, functions that exist only for use by type-generic macros 
> > > should not have such aliases).  Functions would go in libc or libm 
> > > according to what header has the declaration, unless consistency with 
> > > existing functions dictates otherwise (e.g. __isinff128 might go in libc 
> > > because other __isinf* functions are there).
> > 
> > Are you able to point out the relevant clauses in ISO C for this? I want to
> > make sure I understand these rules well.
> 
> The rule about using a function without a header is in C11 7.1.4#2: 
> "Provided that a library function can be declared without reference to any 
> type defined in a header, it is also permissible to declare the function 
> and use it without including its associated header.".  This applies to the 
> vast majority of libm functions.
> 
> The rule about which library a function goes in, based on the header, 
> comes from POSIX's definition of the c99 utility, saying libm is for 
> functions declared in <math.h>, <complex.h> and <fenv.h>.  I think this 
> continues to work fine for TS 18661 parts 1, 3 and 4.
> 
> > > * While working on it, it's important to pay attention to how the work 
> > > relates to the details of TS 18661 and to ongoing discussions in WG14 and 
> > > to track cases where possible issues or ambiguities in TS 18661 are found 
> > > - and to pass such information back to WG14 for consideration when it's 
> > > considered whether to include parts of TS 18661 in the next revision of 
> > > the C standard (actually having an implementation of parts of part 3 might 
> > > make it more likely to be included in the next revision).
> 
> Note especially that there is a change to <tgmath.h> (for an issue I 
> identified regarding different feature test macros being defined when 
> different headers are included - ISO C feature test macros working 
> differently from the existing glibc ones) in the floating-point working 
> group's current draft of *part 2* of the TS, postdating the publication of 
> parts 1 to 4, which may be relevant to part 3.  Probably the fixes in the 
> current drafts will soon become DRs against the published parts of the TS.
> 
>   Changes to C11 + TS18661-1:
> 
>   To 7.25 #1, append the sentence:
> 
>   It declares function identifiers that would be declared if <math.h> and 
>   <complex.h> were included by <tgmath.h>, even if <math.h> or <complex.h> 
>   were included prior to <tgmath.h> in a context where the identifiers were 
>   not declared.
> 
> There are implications for the design of how glibc handles declaring 
> functions for different floating-point types.  It's not clear how best to 
> address those.
>