Language options are not available when a target is being created,
thus, a new method is introduced. Also, some refactoring is done,
such as removing OpenCL feature macros setting from TargetInfo.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Just a few nitpicks otherwise it looks great!
| clang/include/clang/Basic/DiagnosticCommonKinds.td | ||
|---|---|---|
| 364 | -> warn_opencl_unsupported_core_feature | |
| 365 | let's maybe also print OpenCL version explicitly? We already have some logic for it in other diagnostics i.e. warn_opencl_attr_deprecated_ignored although I appreciate it seems to be broken for C++ for OpenCL. But we can take care of it separately. | |
| clang/lib/Basic/Targets.cpp | ||
| 737 | This is just an idea perhaps not for this change - maybe we could introduce static methods for OpenCLOptions::OpenCLOptionInfo to allow checking if the features are core or available? Then we can avoid creating temporary objects here and in InitializeOpenCLFeatureTestMacros? | |
| clang/lib/Frontend/InitPreprocessor.cpp | ||
| 610 | I think that the second part of this comment can now be removed
| |
Addressed comments, did some more refactoring. Is it OK to have "2.0" diagnostics for C++ for OpenCL?
| clang/include/clang/Basic/DiagnosticCommonKinds.td | ||
|---|---|---|
| 365 | 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. | |
| clang/include/clang/Basic/OpenCLOptions.h | ||
| 173 | 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. | |
| clang/include/clang/Basic/OpenCLOptions.h | ||
|---|---|---|
| 173 | In future I would like to have a file scope variable to to something like: extern llvm::StringMap<OpenCLOptionInfo> OpenCLOptionsKV = {
#include "OpenCLExtensions.inc"
};where OpenCLExtensions.inc will be generated from TableGen file. This file-scope variable will be initialized once and contain all the information about OpenCL options. As for now I think using variadics and creating a temporary variable is much more simple than obtaining a full list of arguments and choosing the proper one to call CLVer >= Avail and even for checking core :) | |
LGTM! Thanks.
I have made a minor suggestion to testing that could be addressed in the final commit.
| clang/test/Misc/nvptx.unsupported_core.cl | ||
|---|---|---|
| 2 | We could add a line with -cl-std=CLC++ to check the full wording of the new diagnostic. | |
-> warn_opencl_unsupported_core_feature