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 testcases. > 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 jos...@codesourcery.com
