Fix __has_builtin to return 1 only if the requested target features
of a builtin are enabled by refactoring the code for checking
required target features of a builtin and use it in evaluation
of __has_builtin.
Details
- Reviewers
tra aaron.ballman rsmith - Commits
- rGcefe472c51fb: [clang] Fix __has_builtin
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
@echristo - FYI, in case you have an opinion on target builtin feature checks.
clang/include/clang/Basic/Builtins.h | ||
---|---|---|
264 | I think we should boil it down to just evaluateRequiredTargetFeatures(StringRef RequiredFeatures, ... TargetFeatureMap). | |
clang/lib/Basic/BuiltinTargetFeatures.h | ||
33 | I don't think it needs to be part of the public API. Feature check function operates on llvm::StringMap<bool> and does not need to know about this class, and the implementation of this class can be moved into Builtins.cpp where it's actually used. |
clang/include/clang/Basic/Builtins.h | ||
---|---|---|
264 | will do | |
clang/lib/Basic/BuiltinTargetFeatures.h | ||
33 | It is not a public API since it is under lib/Basic. The reason it is made a header file because we have a unit test clang/unittests/CodeGen/CheckTargetFeaturesTest.cpp for class TargetFeatures. This is because TargetFeatures is relatively complicated. |
LGTM with a possible nit.
clang/lib/Basic/BuiltinTargetFeatures.h | ||
---|---|---|
33 | Got it. I've missed the test. | |
clang/lib/CodeGen/CodeGenFunction.cpp | ||
2552–2553 | Should we move that into the evaluateRequiredTargetFeatures ? Empty feature list -> true sounds like something that belongs to the evaluation logic. So does the assertion on the no-spaces assumption we make about the input. |
clang/lib/CodeGen/CodeGenFunction.cpp | ||
---|---|---|
2552–2553 | will do when committing |
I think we should boil it down to just evaluateRequiredTargetFeatures(StringRef RequiredFeatures, ... TargetFeatureMap).