[cfe-commits] RFC: Half floating point support

Anton Korobeynikov anton at korobeynikov.info
Wed Oct 5 01:48:54 PDT 2011

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

With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

More information about the cfe-commits mailing list