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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
