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

[Anton Korobeynikov]

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

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