On 18/05/16 16:20, Joseph Myers wrote:
On Wed, 18 May 2016, Matthew Wahab wrote:
AArch64 follows IEEE-754 but ARM (AArch32) adds restrictions like
flush-to-zero that could affect the outcome of a calculation.
The result of a float computation on two values immediately promoted from
fp16 cannot be within the subnormal range for float. Thus, only one flush
to zero can happen, on the final conversion back to fp16, and that cannot
make the result different from doing direct arithmetic in fp16 (assuming
flush to zero affects conversion from float to fp16 the same way it
affects direct fp16 arithmetic).
[..]
In short: instructions for direct HFmode arithmetic should be described
with patterns with the standard names. It's the job of the
architecture-independent compiler to ensure that fp16 arithmetic in the
user's source code only generates direct fp16 arithmetic in GIMPLE (and
thus ends up using those patterns) if that is a correct representation of
the source code's semantics according to ACLE.
The intrinsics you provide can then be written to use direct arithmetic,
and rely on convert_to_real_1 eliminating the promotions, rather than
needing built-in functions at all, just like many arm_neon.h intrinsics
make direct use of GNU C vector arithmetic.
I think it's clear that this has exhausted my knowledge of FP semantics.
Forcing promotion to single-precision was to settle concerns brought up in internal
discussions about __fp16 semantics. I'll see if anybody has any problem with the
changes you suggest.
Thanks,
Matthew
