This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Implement C _FloatN, _FloatNx types [version 2]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, <fortran at gcc dot gnu dot org>, <jason at redhat dot com>, <richard dot earnshaw at arm dot com>, <nickc at redhat dot com>, <ramana dot radhakrishnan at arm dot com>, <marcus dot shawcroft at arm dot com>, <dje dot gcc at gmail dot com>, <segher at kernel dot crashing dot org>, <murphyp at linux dot vnet dot ibm dot com>, <bje at gnu dot org>, Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>, Steve Munroe <sjmunroe at us dot ibm dot com>
- Date: Tue, 21 Jun 2016 21:18:31 +0000
- Subject: Re: Implement C _FloatN, _FloatNx types [version 2]
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 20 dot 1606211202040 dot 4526 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 20 dot 1606211738200 dot 31330 at digraph dot polyomino dot org dot uk> <20160621205302 dot GA8544 at ibm-tiger dot the-meissners dot org>
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