[PATCH] Add support to promote f16 to f32

[Stephen Canon]

> On Apr 1, 2015, at 5:56 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote:
> 
> On Wed, Apr 1, 2015 at 11:49 AM, Pirama Arumuga Nainar
> <pirama at google.com> wrote:
>> On Wed, Apr 1, 2015 at 11:22 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
>> wrote:
>>> Why not just always promote when f16 isn't legal but f32 is?
>> 
>> 
>> For one, I didn't want to do this non-intrusively and not affect others
>> relying on old behavior.  But as you mentioned, the old behavior is to
>> crash, so this'd be better as the default.
>> 
>> The second reason is that I am unsure if keeping intermediate results as f32
>> will break someone's precision assumptions.
> 
> There's several aspects of this.  First, I know this isn't really the
> point, but IEEE 754-2008 only defines f16 as an interchange - not
> arithmetic - format, so we can do whatever we want, and promotion to
> f32 is the usual (dare I say expected) behavior.  We can make this
> possibility extra explicit in the LangRef perhaps?
> 
> As for the actual precision issue, from my very ignorant skim of
> Figueroa's "A Rigorous Framework for Fully Supporting the IEEE
> Standard" (2000), specifically 6.4, I think it's OK to promote if we
> convert back to the narrow precision between each operation (I
> *believe* that applies to half to single precision as well, see 6.2).

Sorry for the delayed response.  Yes, promoting to f32 for arithmetic suffices to deliver correctly-rounded f16 results.  That said, my opinion is that clang should adopt the n1784 semantics for FLT_EVAL_METHOD=0, where any binary floating-point arithmetic involving types smaller than float is promoted to float, and not repeatedly rounded back to the narrower type.  I don’t believe that there’s any call to support FLT_EVAL_METHOD=16 at this point.

– Steve