This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 
those functions).

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]