[PATCH] D101087: [OpenCL] Introduce new method for validating OpenCL target

Anastasia Stulova via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Apr 23 07:16:11 PDT 2021


Anastasia added inline comments.


================
Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:365
+def warn_opencl_unsupported_core_feature : Warning<
+  "%0 is a core feature in OpenCL C %1 but not supported on this target">,
+  InGroup<OpenCLCoreFeaturesDiagGroup>, DefaultIgnore;
----------------
I would prefer:

`OpenCL C` -> `OpenCL version`

then it should cover better C++ for OpenCL as it is aligned with OpenCL versions. This is also more consistent with how we report most of the diagnostics with language versions.

But in the future, I want to refactor the diagnostics to have wording about OpenCL C and C++ for OpenCL separately, like we already do in `err_opencl_unknown_type_specifier` that uses the following helper https://clang.llvm.org/doxygen/classclang_1_1LangOptions.html#a730c1c883221b87b7c3aaec4327b814b

We definitely need a separate pass over diagnostic wording and how we report OpenCL language versions. 


================
Comment at: clang/include/clang/Basic/OpenCLOptions.h:179
+  static bool isOpenCLOptionCoreIn(const LangOptions &LO, Args &&... args) {
+    return OpenCLOptionInfo(std::forward<Args>(args)...).isCoreIn(LO);
+  }
----------------
Do you think we could avoid constructing the temporary objects somehow?

I.e. could we just check the condition `CLVer >= Avail` that is used in the non-static member function directly?

We could then use these helpers in the non-static members perhaps to avoid duplication.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101087/new/

https://reviews.llvm.org/D101087



More information about the cfe-commits mailing list