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

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

On Tue, Jun 21, 2016 at 05:41:36PM +0000, Joseph Myers wrote:
> [Changes in version 2 of the patch:
> 
> * PowerPC always uses KFmode for _Float128 and _Float64x when those
>   types are supported, not TFmode.

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;
	  else
	    return VOIDmode;

	case 128:
	  return VOIDmode;

	default:
	  /* Those are the only valid _FloatNx types.  */
	  gcc_unreachable ();
	}
    }
  else
    {
      switch (n)
	{
	case 32:
	  return SFmode;

	case 64:
	  return DFmode;

	case 128:
	  if (TARGET_FLOAT128)
	    return (TARGET_IEEEQUAD) ? TFmode : KFmode;
	  else
	    return VOIDmode;

	default:
	  return VOIDmode;
	}
    }
}

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.

As Richard Biener and I discussed, the way I created the types using
FRACTIONAL_FLOAT_MODE for IFmode/KFmode isn't really ideal.
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01114.html

It would have made things simpler if there was a MD hook to control what
automatically widens to what.  I tried to implement it in the early days, but I
never came up with code that did what I wanted.  I use rs6000_invalid_binary_op
to do this to some extent.

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.

> No GCC port supports a floating-point format suitable for _Float128x.
> Although there is HFmode support for ARM and AArch64, use of that for
> _Float16 is not enabled.  Supporting _Float16 would require additional
> work on the excess precision aspects of TS 18661-3: there are new
> values of FLT_EVAL_METHOD, which are not currently supported in GCC,
> and FLT_EVAL_METHOD == 0 now means that operations and constants on
> types narrower than float are evaluated to the range and precision of
> float.  Implementing that, so that _Float16 gets evaluated with excess
> range and precision, would involve changes to the excess precision
> infrastructure so that the _Float16 case is enabled by default, unlike
> the x87 case which is only enabled for -fexcess-precision=standard.
> Other differences between _Float16 and __fp16 would also need to be
> disentangled.

ISA 3.0 (Power9) does have instructions to convert to/from 16-bit floating
point to 32-bit floating point.  Right now, it is just conversion to/from
storage format to a more normal format (similar to _Decimal32 where there are
no instructions to operate on 32-bit decimal data).  At the moment, we don't
have support for these instructions, but we will likely do it in the future.

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.

> 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.

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.

As I said in my previous message, what ever we do in this space needs to be
backwards compatible with existing usage in GCC 6.x.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797