This is the mail archive of the
mailing list for the GCC project.
Re: Implement C _FloatN, _FloatNx types [version 3]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, <jason at redhat dot com>, <richard dot earnshaw at arm dot com>, <ramana dot radhakrishnan at arm dot com>, <marcus dot shawcroft at arm dot com>, <nd at arm dot com>
- Date: Thu, 28 Jul 2016 22:43:25 +0000
- Subject: Re: Implement C _FloatN, _FloatNx types [version 3]
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.firstname.lastname@example.org> <alpine.DEB.email@example.com> <alpine.DEB.firstname.lastname@example.org> <20160719112907.GA14200@arm.com>
On Tue, 19 Jul 2016, James Greenhalgh wrote:
> These slightly complicate the description you give above as we now want
> two behaviours. Where the 16-bit floating point extensions are available,
> we want to use the native operations (FLT_EVAL_METHOD == 16). Where they
> are not available we want to use promotion to float (FLT_EVAL_METHOD == 0).
That's not a complication since TARGET_FLT_EVAL_METHOD already can and
does depend on target options.
The complications are that the present excess precision support includes
code to default the options (in c-opts.c:c_common_post_options and
toplev.c:init_excess_precision), and then to use them (in
tree.c:excess_precision_type and c-cppbuiltin.c:c_cpp_builtins), that (a)
only handles the C99/C11 values, (b) ignores the possibility of types
narrower than float and (c) assumes, when determining the defaults, that
excess precision is x86-style, i.e. the back end pretending to have
operations it does not have and C99-style excess precision being
inefficient so only desired in standards conformance modes.
(a) and (b) are straightforward to fix. But to fix (c), first you need to
work out the design for how you actually want the compiler to behave for
ARM / AArch64, for both FLT_EVAL_METHOD values, outside standards
conformance modes. Then you need to work out what that means for the
initialization of the relevant variables, inside and outside standards
conformance modes (remembering that for most targets, all the excess
precision logic *can* be elided because there aren't any types narrower
than float and so FLT_EVAL_METHOD == 0 really does mean no excess
precision). And you need to make all the functions I listed respect the
new values and the new semantics for the value 0, and add appropriate
> I'm hoping that enabling _Float16 for ARM/AArch64 should not be too
> difficult with the groundwork in your patches, but I would appreciate any
> pointers on where I am likely to run in to trouble; I haven't worked in the
> front-end before.
The actual C front-end code, outside of the functions I listed, should not
require any changes; it just uses excess_precision_type.
You do need to make appropriate arrangements for _Complex _Float16
arithmetic. See PR 63250. For things to work when you don't promote
(FLT_EVAL_METHOD == 16) you'll need to arrange for the relevant libgcc
functions to be built for HCmode (cf. the powerpc float128 issue of
needing to build them for KCmode to avoid the present duplicate copies of
Joseph S. Myers