On Thu, Jun 23, 2016 at 02:19:52PM +0000, Joseph Myers wrote:

<snip>

> No GCC port supports a floating-point format suitable for _Float128x.
> Although there is HFmode support for ARM and AArch64, use of that for
> _Float16 is not enabled.  Supporting _Float16 would require additional
> work on the excess precision aspects of TS 18661-3: there are new
> values of FLT_EVAL_METHOD, which are not currently supported in GCC,
> and FLT_EVAL_METHOD == 0 now means that operations and constants on
> types narrower than float are evaluated to the range and precision of
> float.  Implementing that, so that _Float16 gets evaluated with excess
> range and precision, would involve changes to the excess precision
> infrastructure so that the _Float16 case is enabled by default, unlike
> the x87 case which is only enabled for -fexcess-precision=standard.
> Other differences between _Float16 and __fp16 would also need to be
> disentangled.

Hi Joseph,

Thanks for the patch. Just to let you know, I'm interested in trying to
enable _Float16 for ARM/AArch64, and I'll be starting work on that once
Jiong and Matthew's support for the ARMv8.2-A 16-bit floating point
arithmetic extensions go in.

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).
I'm hoping that the excess precision mechanics will be able to handle
this, and from your description above it sounds like making it work in the
presence of the 16-bit arithmetic extensions will be easier as I won't have
to modify the excess precision machinery much.

As you say, I've also got a few things to do to disentangle _Float16 and
__fp16. __fp16 should continue to always evaluate in excess precision, and
we want it to continue to exist as a distinct type for compatability. My
guess is that keeping this separation might not be too hard, I should
only need to change TARGET_PROMOTED_TYPE to promote if it sees an
__fp16 type, and do nothing otherwise.

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.
 
Thanks,
James

Reply via email to