[cfe-dev] [RFC] implementation of _Float16

[Martin J. O'Riordan via cfe-dev]

Hi Hubert,

 

I only just realised that I left your comment unanswered, things got busy and it fell through a crack.

 

Yes, you are absolutely right; when I refer to ‘short float’ I am thinking of it as being a discrete type where ‘float’ can represent all the values that ‘short float’ can, ‘double’ can represent all the values ‘float’ can, and ‘long double’ can represent all the values that ‘double’ can.  But this does not dictate or imply any particular implementation, unlike ‘_Float16’.  Indeed, all four types could have an identical implementation and representation, though from the perspective of the type system they are discrete.  The types ‘_FloatN’ are quite different as they are explicit about the representation.

 

Having such an additional type would provide a little flexibility on the small end of Floating-Point.  Our target has native FPU support for 32-bit and 16-bit, while 64-bit is using an software library.  Because ‘float’ floating-point arithmetic in C is performed after promotion to ‘double’, we have chosen to represent both ‘float’ and ‘double’ as IEEE 32-bit, and ‘long double’ as IEEE 64-bit.  And I chose for consistency with the usual arithmetic rules, to introduce a new type ‘short float’ which in my implementation I have bound to IEEE 16-bit, but it could be bound to any representation for some given target.

 

But true integration of such a type would need to be formally specified, and how it interacts with overloading, usual arithmetic conversions and other aspects of C and C++ would need to be properly determined before it could be considered in any way a candidate for Standardisation.

 

LLVM and CLang already have infrastructure for supporting the ‘half’ data-type for OpenCL, and though OpenCL has strict definitions for the types ‘half’, ‘float’ and ‘double’, the definition of ‘half’ works quite well for our purposes, so I chose to bind the syntax ‘short float’ to LLVM and CLang’s implementation of OpenCL’s ‘half’.  I didn’t want to reserve the keyword ‘half’ in C or C++, and ‘__fp16’ isn’t quite the same thing.  In practice this works quite well, and the code generation is really good.  Of course, there is the inconsistency that ‘short float’ is not promoted to ‘double’ to perform arithmetic which is at variance with how ‘float’ is handled (though I do promote it to ‘double’ for passing as an argument to variadic functions such as ‘printf’).

 

All the best,

 

            MartinO

 

From: Hubert Tong [mailto:hubert.reinterpretcast at gmail.com] 
Sent: 10 May 2017 22:23
To: Martin J. O'Riordan <martin.oriordan at movidius.com>
Cc: Hal Finkel <hfinkel at anl.gov>; Sjoerd Meijer <Sjoerd.Meijer at arm.com>; clang developer list <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] [RFC] implementation of _Float16

 

On Wed, May 10, 2017 at 9:13 AM, Martin J. O'Riordan via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > wrote:

More controversially we also added a “synonym” for this using ‘short float’ rather than ‘_Float16’ (or OpenCL’s ‘half’), and created a parallel set of the ISO C library functions using ‘s’ to suffix the usual names (e.g. ‘tan’, ‘tanf’, ‘tanl’ plus ‘tans’).

Perhaps a bit of a tangent here with regards to language semantics. I am going to guess that, in general, short float is not necessarily the same format as _Float16. So it follows that if both are present, then _Float16 and short float are types which are not compatible (e.g., for _Generic) with each other. This would be consistent with _Float32 and "plain" float.

-- HT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170616/4e69698c/attachment.html>