This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.
On 15/07/2019 16:44, Barnaby Wilks wrote:
Yep agreed, a dedicated directive would make more sense really - originally I did have something
along those lines (.ieee_fp16_format/.alternative_fp16_format directives for switching between formats), but then
changed upon finding a EABI attribute for the same thing, and seeing that was how GCC did it.
Like you say though, for files that contain a mix of float16's in both IEEE and Alternative formats what would be the
EABI attribute for that be?
This could be solved by just restricting to one format (in which
case a command line option may make more sense), or by inventing
a new EABI attribute? (I'm don't really know much about that, so have no idea if it's feasible).
GCC already has the command-line option
-mfp16-format=(none|ieee|alternative). I'd suggest we have the same,
and have an assembly attribute directive with a similar style.
For the directive, however, the default can be a little more lax: I
think the assembler should start in a mode where the format is
'tentatively ieee' format. Then, if a .float16 appears with no format
override, we'd make that an explicit format selection. At the end of
assembly, when then generating build attributes (if doing that
automatically, we'd update the build attributes if the format is at that
The tentative nature is important to avoid changing behaviour for
existing files: we don't want them to start writing out additional build
attributes that they did not generate previously, however, ieee format
is far more common than than alternative format, so requiring users to
always specify this before ever using .float16 would be a little awkward.
On 7/15/19 10:16 AM, Richard Earnshaw (lists) wrote:
On 11/07/2019 16:26, Barnaby Wilks wrote:
This is part of a patch series that implements a directive for
assembling 16-bit floating point constants for Arm and AArch64.
This patch implements the float16 directive for both the IEEE 754
format and the Arm alternative format for the
Arm backend >
The syntax of the directive is:
.float16 <0-n decimal numbers>
.float16 0.23, 433.1, 0.06
The Arm alternative format is almost identical to the IEEE 754
format, except that it doesn't
encode for NaNs or Infinity (instead an exponent of 0x1F represents a
normalized number in the range
65536 to 131008).
The alternative format is documented in the reference manual:
Which format is used is controlled by the
.eabi_attribute Tag_ABI_FP_16bit_format, <...>
directive, where if
<...> = 1 then use the IEEE 754 half-precision format else if
<...> = 2 then use the Arm alternative format
Added testcases to verify the correct encoding for both formats (for
both big and little endian targets),
as well as tests verifying that warnings are thrown if trying to
encode NaN or Infinity when using
the Arm alternative format.
The encodings have been cross referenced with GCC's encoding for
__fp16 types to ensure consistency.
Cross compiled and regtested on arm-none-eabi and
I don't have write access, so if it's OK then could someone commit on
thanks for the patch.
I'm not sure that using the build attributes to control selection of
the format is the best idea. Firstly, build attributes are not
available when not assembling for ELF (we have PE-coff support in the
assembler as well); secondly, build attributes should reflect what was
placed in the assembly file, not control what goes into it. So this
is a case of the coach before the horse.
I think, if we want to support the Arm alternate FP format in GAS at
all, we need either a new command line option, or a new directive (or
possibly both). Then the code in BFD that does automatic
build-attribute selection should be updated to reflect the tri-state
situation: no format specified; IEEE format specified; or ARM
Alternate format specified.
Note that GAS can currently only reflect show build attributes that
affect the whole file, so switching during assembly is a little
dubious as things stand.
2019-07-11 Barnaby Wilks<email@example.com>
* config/tc-arm.c (md_atof): Set precision for float16 type.
(enum fp_16bit_format): Add enum to represent the 2 float16
(arm_is_largest_exponent_ok): Check for whether to encode with
the IEEE or alternative
* config/tc-arm.h (TC_LARGEST_EXPONENT_IS_NORMAL): Macro that
(arm_is_largest_exponent_ok): Add prototype for
* testsuite/gas/arm/float16-bad.d: New test.
* testsuite/gas/arm/float16-bad.l: New test.
* testsuite/gas/arm/float16-bad.s: New test.
* testsuite/gas/arm/float16-be.d: New test.
* testsuite/gas/arm/float16-be.s: New test.
* testsuite/gas/arm/float16-le.d: New test.
* testsuite/gas/arm/float16-le.s: New test.