[PATCH] D97058: [OpenCL] Refactor diagnostic for OpenCL extension/feature
Anastasia Stulova via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Mar 2 03:37:35 PST 2021
Anastasia added a comment.
In D97058#2587033 <https://reviews.llvm.org/D97058#2587033>, @azabaznov wrote:
>> FYI, I would even be ok if we remove the need for enabling non-core
>
> AFAIU this can be done not for every extension to maintain backward compatibility.
This should not result in any backward compatibility issues, as the old kernels using `pragma enable` will still compile successfully.
> Also, I imagine that implicit type definition is not needed if no pragma required.
They need to be added but conditionally on language version or extension/feature support. If there is no support they should not be added as identifiers by the compiler and therefore can be reused by the developers in the application code.
================
Comment at: clang/lib/Sema/Sema.cpp:360
setOpenCLExtensionForType(Context.DoubleTy, "cl_khr_fp64");
----------------
azabaznov wrote:
> Anastasia wrote:
> > I think the same should apply to `double` not only `atomic_double`?
> I think `double` is created in a place where it's not possible to guard it with OpenCL extensions support. I will double-check.
That's right, `double` is a reserved identifier so we should always accept it. However, we should allow its use as a legal type without the pragma if `fp64` is supported. We could remove this statement here and add a separate check for it in `Sema`, but we could also modify this mechanism to check for the extensions/features being supported instead of being enabled.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D97058/new/
https://reviews.llvm.org/D97058
More information about the cfe-commits
mailing list