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