[PATCH] Add support to promote f16 to f32

[Ahmed Bougacha]

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).

I think we can achieve that by replacing all instances of:
    GetPromotedFloat(N)
with:
    DAG.getNode(ISD::FP16_TO_FP, dl, MVT::f32,
DAG.getNode(ISD::BITCAST, dl, MVT::i16, N))

But I don't think we need to worry about this yet.  It's not ideal,
but if someday, someone's assumptions are broken, we'll see about
fixing it (we'll end up with our very own Bug #323 =])  In the
meantime, a LangRef change would avoid that.

-Ahmed