[cfe-commits] RFC: Half floating point support

[John McCall]

On Oct 5, 2011, at 1:48 AM, Anton Korobeynikov wrote:

>> Right.  I'm not sure what we should do about it, but "emit an external reference and assume it resolves" is probably not it.
> Ok, let's live w/o rtti for half at least for now. Looks like very low
> important :)
> 
>>>> +    ICS.Standard.setToType(0, Context.FloatTy);
>>>> +    AddConversionSequenceStep(ICS, Entity.getType());
>>>> 
>>>> This should be modeled in the standard-conversion logic.
>>> What do you mean?
>> 
>> I mean that adding a single implicit conversion step should be sufficient, and then PerformImplicitConversion should generate the AST you want from that.
> Well, maybe. I just wanted to play 'safe' - I just did not know
> whether we might have complex conversion paths for __fp16 and tried to
> 'preserve' almost all logic here. I'll think about this case.
> 
>>> Here foo(float) should be selected.
>> Okay, but if foo(float) doesn't exist, foo(double) should be selected.  So there's at least a floating-point conversion from half to double.
> I'll check this case. The codegen for half <-> double conversion is
> done during codegen stage via implicit conversion to float step (so,
> we'll have half <-> float <-> double conversion chain).
> 
>> If you really think it's important, the appropriate thing to do would be to make PerformImplicitConversion do it in ICK_BooleanConversion.
> Ok. The main problem is that precise semantics of __fp16 operations
> are not defined. So, I'm just trying to strictly follow the "all
> operations should be promoted to float" clause :)

Is there a standard we should be following here?  Without one, my inclination is to treat it as a normal floating-point type, without this extra promotion stuff, and then just have IR generation know that half operations should actually be done in float.

John.