[cfe-dev] [OpenCL patch] Half type as native when OpenCL's cl_khr_fp16 extension is enabled

John Garvin jgarvin at apple.com
Mon Jun 25 15:49:42 PDT 2012


On Jun 21, 2012, at 8:28 AM, Anton Korobeynikov wrote:

>>> However, that seems like something that would also impact our semantic
>>> analysis. I don't have a solid understanding of the similarities and
>>> differences between the OpenCL and ARM NEON's half types, but from your
>>> patch it's starting to feel like they are conceptually different types.
>> I'm looking to Anton Korobeynikov here (who I believe left this comment), as
>> I'm only vaguely familiar with the NEON half semantics.  Do you think we
>> should have a LangOpt such as HalfTypeNative, which would be always enabled
>> for OpenCL, with a typical pattern of:
>> 
>>> -    if (type->isHalfType()) {
>>> +    if (type->isHalfType() &&
>> !CGF.getContext().getLangOpts().HalfTypeNative)
>> 
>> This would probably be a reasonable refactoring if any language dialect
>> other than OpenCL needs to use the half type natively.
> +1
> 
> The semantics of half being storage only type vs native type is
> definitely different. E.g. in the former case we should prohibit all
> the possible usages which might end with bare 'half' type and not
> half*.

This LangOpt seems like a good idea to me. I wonder if it should be expressed as HalfTypeNative (use convert.*.fp16 if false) or as something like PromoteHalfToFloat (use convert.*.fp16 if true). I lean slightly toward PromoteHalfToFloat, but I don't have a strong opinion.

It looks like we have four possibilities. Is this right?
1. half is completely unsupported (C, C++ default)
2. half is storage-only, support half* but no operations on half (OpenCL without cl_khr_fp16)
3. half is storage-only, operations on half automatically promoted to float (__fp16 NEON)
4. half is completely supported (OpenCL with cl_khr_fp16)

HalfTypeNative (or PromoteHalfToFloat) would differentiate between the last two cases in CodeGen; the first two cases are irrelevant in CodeGen because in those cases it should be impossible to pass a half type to EmitScalarConversion.

John



More information about the cfe-dev mailing list