[llvm] [AArch64][TargetParser] autogen ArchExtKind enum (PR #90314)
Jack Styles via llvm-commits
llvm-commits at lists.llvm.org
Tue Apr 30 06:09:06 PDT 2024
================
@@ -9,32 +9,43 @@
//
//===----------------------------------------------------------------------===//
+// A SubtargetFeature that can be toggled from the command line, and therefore
+// has an AEK_* entry in ArmExtKind.
+class Extension<
+ string TargetFeatureName, // String used for -target-feature.
+ string Spelling, // The XYZ in HasXYZ and AEK_XYZ.
+ string Desc, // Description.
+ list<SubtargetFeature> Implies = [] // List of dependent features.
+> : SubtargetFeature<TargetFeatureName, "Has" # Spelling, "true", Desc, Implies>
+{
+ string ArchExtKindSpelling = "AEK_" # Spelling; // ArchExtKind enum name.
+}
+
// Each SubtargetFeature which corresponds to an Arm Architecture feature should
// be annotated with the respective FEAT_ feature name from the Architecture
// Reference Manual. If a SubtargetFeature enables instructions from multiple
// Arm Architecture Features, it should list all the relevant features. Not all
// FEAT_ features have a corresponding SubtargetFeature.
-def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8", "true",
- "Enable ARMv8 FP (FEAT_FP)">;
+def FeatureFPARMv8 : Extension<"fp-armv8", "FPARMv8", "Enable ARMv8 (FEAT_FP)">;
-def FeatureNEON : SubtargetFeature<"neon", "HasNEON", "true",
+def FeatureNEON : Extension<"neon", "NEON",
----------------
Stylie777 wrote:
For the field name, how are we now handling guarding instructions? There are a number of instances where `HasNEON` is used to ensure the subtarget has the feature. Will this change affect this?
https://github.com/llvm/llvm-project/pull/90314
More information about the llvm-commits
mailing list