Re: Implement C _FloatN, _FloatNx types [version 2]

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 21 Jun 2016, Michael Meissner wrote:

> While from one perspective, it would have been cleaner if the PowerPC
> had separate internal types for IBM extended double and IEEE 128-bit floating
> point.  But the way the compiler has been implemented is that TFmode is which
> ever type is the default.  Typically, in the Linux environment, this is IBM
> extended double, but we are hoping in the future to change the default to make
> long double IEEE 128-bit.  So, I think we need to do something like:
> 
> static machine_mode
> rs6000_floatn_mode (int n, bool extended)
> {
>   if (extended)
>     {
>       switch (n)
> 	{
> 	case 32:
> 	  return DFmode;
> 
> 	case 64:
> 	  if (TARGET_FLOAT128)
> 	    return (TARGET_IEEEQUAD) ? TFmode : KFmode;

That's essentially what I had in the first patch version.  I.e., you and 
Bill are making contradictory statements about whether always to use 
KFmode (in which case *q constants should be fixed to match) or whether to 
prefer TFmode when it's binary128 (in which case no fixes beyond my patch 
(with the first version of this function) are needed as my patch will make 
__float128 into an alias for _Float128, which will prefer TFmode when it's 
binary128).

> As an aside, one of the issues, I'm currently grappling with is how to enable
> the __float128 machinery without enabling the __float128 keyword (PR 70589).
> The reason is we need to create the various built-in functions for IEEE 128-bit
> functions, which means creating the type and keyword support.

Perhaps it would be best not to allow __float128 to be disabled?  I.e. 
have it always available for 64-bit and never available for 32-bit (or 
something like that).  Or at least don't allow it to change during the 
source file.  Because we want these functions to end up in generic code 
rather than target-specific.  And at least the C-family built-ins 
machinery handles not creating a built-in function if its type would be 
error_mark_node, and using error_mark_node for types derived from 
error_mark_node.  That is, if in the generic code we have

DEF_PRIMITIVE_TYPE (BT_FLOAT128, float128_type_node ? float_128_type_node : error_mark_node)

in builtin-types.def, then it should be possible to list all the relevant 
functions in builtins.def and have them only created when the type is 
enabled.  But you'll run into problems if there are conditions for 
function availability changing part way through the source file....  
(There's existing machinery for targets to change built-in function 
availability part way through the source file, but it seems likely to be 
nasty to apply that to target-independent functions.)

> Another thing that I'm grappling with is how to identify when the floating
> point emulation functions have been built.  Right now, it is only built for
> 64-bit Linux systems, and it is not built for AIX, BSD, or the various 32-bit
> embedded targets.

See the libgcc_floating_mode_supported_p hook.  (It doesn't do much, and 
you might need to implement it for your target, but it's the right idea.)

> However, I suspect that in the future, we may have users that want to do
> arithmetic in this format (particularly vectors).  This comes from people
> wanting to interface with attached GPUs that often times support HFmode, and
> with machine learning systems that does not need the precision.  So, we should
> at least think what is needed to enable HFmode as a real type.

Basically, you need to define an ABI, and you need changes to excess 
precision support which is currently geared to the x87 case.

> > GCC has some prior support for nonstandard floating-point types in the
> > form of __float80 and __float128.  Where these were previously types
> > distinct from long double, they are made by this patch into aliases
> > for _Float64x / _Float128 if those types have the required properties.
> 
> And of course other machine dependent non-standard floating point types 
> such as IBM extended double.

Which cannot be _FloatN / _FloatNx types; those names are strictly for 
types with IEEE semantics (and representation, in the _FloatN case).  
float, double and long double are much more flexible about possible 
formats than _FloatN and _FloatNx.

> In addition, there is the question of what to do on the embedded machines that
> might use IEEE format for floating point, but does not support all of the
> features in IEEE 754R such as NaNs, infinities, de-normal numbers, negative 0,
> etc.

Those also cannot be _FloatN / _FloatNx types.  Note how my real.c changes 
mark spu_single_format as not suitable for such a type.

-- 
Joseph S. Myers
joseph@codesourcery.com