[flang-commits] [flang] [clang] [llvm] [AArch64][Driver] Better handling of target feature dependencies (PR #78270)

[David Spickett via flang-commits]

================
@@ -308,6 +312,94 @@ inline constexpr ExtensionInfo Extensions[] = {
 };
 // clang-format on
 
+struct ExtensionSet {
+  // Set of extensions which are currently enabled.
+  ExtensionBitset Enabled;
+  // Set of extensions which have been enabled or disabled at any point. Used
+  // to avoid cluttering the cc1 command-line with lots of unneeded features.
+  ExtensionBitset Touched;
+  // Base architecture version, which we need to know because some feature
+  // dependencies change depending on this.
+  const ArchInfo *BaseArch;
+
+  ExtensionSet() : Enabled(), Touched(), BaseArch(nullptr) {}
+
+  // Enable the given architecture extension, and any other extensions it
+  // depends on.
+  void enable(ArchExtKind E);
+  // Disable the given architecture extension, and any other extensions which
+  // depend on it.
+  void disable(ArchExtKind E);
+
+  // Add default extensions for the given CPU.
+  void addCPUDefaults(const CpuInfo &CPU);
+  // Add default extensions for the given architecture version.
+  void addArchDefaults(const ArchInfo &Arch);
+
+  // Add or remove a feature based on a modifier string. The string must be of
+  // the form "<name>" to enable a feature or "no<name>" to disable it. This
+  // will also enable or disable any features as required by the dependencies
+  // between them.
+  bool parseModifier(StringRef Modifier);
+
+  // Convert the set of enabled extension to an LLVM feature list, appending
+  // them to Features.
+  void toLLVMFeatureList(std::vector<StringRef> &Features) const;
+};
+
+struct ExtensionDependency {
+  ArchExtKind Earlier;
+  ArchExtKind Later;
----------------
DavidSpickett wrote:

Yes, if the explanation is "foo was added before bar" then earlier and later is the better choice.

When I was thinking about this problem I always phrased it as "x implies y", which is why it looked backwards to me at first but either is fine as long as it's clearly documented.

https://github.com/llvm/llvm-project/pull/78270