Re: Implement C _FloatN, _FloatNx types

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 4 Aug 2016, Michael Meissner wrote:

> It brings up a general complaint that I had when I started the whole PowerPC
> __float128 adventure is that we have multiple places in the compiler it goes
> through a list of floating point types, and only for the blessed types does it
> do something.  If a port happens to have a non-standard type, there really
> should be target hooks for doing each of the actions.

Note that not all the types / modes are necessarily suitable for all those 
places.  Consider IA64 RFmode (__fpreg), for example.  And some things 
such as <float.h> macros aren't defined for nonstandard types.

> But rather than having lots of different hooks, it may be better to have a hash
> lookup given a type node (and/or mode) that registers all of the handling in a
> central place, rather than continually having:

In various places you need to get the right ordering of types, and to 
distinguish types for the same mode (e.g. usual arithmetic conversions 
have a specified ordering); it's not just a lookup table.

This patch is explicitly not trying to improve anything for types that are 
*not* _FloatN / _FloatNx (such as __fp16, or __fpreg).  For the _FloatN 
and _FloatNx types it tries to use the various macros for looping over 
those types as far as possible, not hardcoding a list of them in too many 
places.

It is also explicitly aiming to get support for _FloatN / _FloatNx to a 
minimal functional state (conforming to the TS semantics, to the extent 
that the underlying arithmetic for the relevant machine modes does, and 
apart from the corner case of treating _FloatN as a keyword for arbitrary 
N >= 128 and a multiple of 32) that can be incrementally improved, rather 
than to make it fully equivalent to that for float, double and long double 
(which runs into issues with adding hundreds of new built-in functions, 
among other things) - that is, to be the smallest version of support for 
these types that would be appropriate for GCC, not the maximal version, in 
accordance with the principle of submitting minimal indivisible patches.  
The list of things not done in the notes for this patch is intended to be 
exhaustive as a list of potential future improvements for bringing these 
types to full parity with float, double and long double.

-- 
Joseph S. Myers
joseph@codesourcery.com