================
@@ -331,15 +331,108 @@ bool MCSubtargetInfo::checkFeatures(StringRef FS) const {
"Feature flags should start with '+' or '-'");
const SubtargetFeatureKV *FeatureEntry =
Find(SubtargetFeatures::StripFlag(F), ProcFeatures);
- if (!FeatureEntry)
- report_fatal_error(Twine("'") + F +
- "' is not a recognized feature for this target");
+ if (!FeatureEntry) {
+ reportFatalInternalError(Twine("'") + F +
+ "' is not a recognized feature for this
target");
+ }
return FeatureBits.test(FeatureEntry->Value) ==
SubtargetFeatures::isEnabled(F);
});
}
+static bool hasFeature(StringRef Feature, const FeatureBitset &FeatureBits,
+ ArrayRef<SubtargetFeatureKV> ProcFeatures) {
+ bool ShouldBeEnabled = true;
+ if (!Feature.consume_front("+") && Feature.consume_front("-"))
+ ShouldBeEnabled = false;
+
+ const SubtargetFeatureKV *FeatureEntry = Find(Feature, ProcFeatures);
+ if (!FeatureEntry) {
+ reportFatalInternalError(Twine("'") + Feature +
+ "' is not a recognized feature for this target");
+ }
+
+ return FeatureBits.test(FeatureEntry->Value) == ShouldBeEnabled;
+}
+
+namespace {
+class FeatureExpressionParser {
----------------
shiltian wrote:
I definitely looked into that. The Clang builtin parser currently lives under
`clang/lib/Basic`, so LLVM MC cannot reuse it directly. It also has Clang
specific lookup/validation behavior. We could factor the grammar parser into a
common LLVM utility with a callback for feature lookup, then use it from both
Clang and MC, but that is a cross-project refactoring of existing Clang
behavior. I'd prefer to keep this PR scoped and consider that as a follow-up if
we really want.
https://github.com/llvm/llvm-project/pull/201470
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
