On Tue, 17 May 2016, Matthew Wahab wrote: > In most cases the instructions are added using non-standard pattern > names. This is to force operations on __fp16 values to be done, by > conversion, using the single-precision instructions. The exceptions are > the precision preserving operations ABS and NEG.
But why do you need to force that? If the instructions follow IEEE semantics including for exceptions and rounding modes, then X OP Y computed directly with binary16 arithmetic has the same value as results from promoting to binary32, doing binary32 arithmetic and converting back to binary16, for OP in + - * /. (Double-rounding problems can only occur in round-to-nearest and if the binary32 result is exactly half way between two representable binary16 values but the exact result is not exactly half way between. It's obvious that this can't occur to + - * and only a bit harder to see this for /. According to the logic used in convert.c:convert_to_real_1, double rounding can't occur in this case for square root either, though I haven't verified that.) So I'd expect e.g. __fp16 a, b; __fp16 c = a / b; to generate the new instructions, because direct binary16 arithmetic is a correct implementation of (__fp16) ((float) a / (float) b). (ISO C, even with DTS 18661-5, does not concern itself with the number of times an expression raises a given exception beyond whether that is zero or nonzero, so changes between two and one instances of "inexact" are not a concern.) -- Joseph S. Myers jos...@codesourcery.com
