On Thu, Jul 28, 2016 at 10:43:25PM +0000, Joseph Myers wrote: > 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).
Hi Joseph, Thanks for this reply, with this I've been able to prototype the _Float16 support for AArch64 and get many of the _Float16 tests you add in this patch, and the patch for builtin functions, passing. However, I still have some trouble with TFmode and TImode conversions. In particular, I'm missing support for the standard names: extendhftf2 trunctfhf2 floattihf2 fixhfti In addition, where the ARMv8.2-A extensions are not available, I have no support for the standard names: floatdihf floatundihf Providing these names through soft-fp in libgcc should be possible. Certainly I can enable extendhftf2 and trunctfhf2 using softfp_extensions/softfp_truncations and providing the appropriate files. Though, I'd rather avoid adding the full suite of soft-float routines, in particular I don't need arithmetic like divhf3. There are probably modifications I can make to the soft-fp build machinery to enable building only specified conversion functions. Is this a sensible approach, or would I be better simply the full suite of HFmode operations that soft-fp expects? Thanks, James
