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

[James Greenhalgh <james dot greenhalgh at arm dot com>]

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