[clang] [llvm] [NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (PR #116257)

Alexandros Lamprineas via cfe-commits cfe-commits at lists.llvm.org
Fri Nov 15 09:49:41 PST 2024


================
@@ -48,6 +48,19 @@ std::optional<AArch64::ArchInfo> AArch64::ArchInfo::findBySubArch(StringRef SubA
   return {};
 }
 
+unsigned AArch64::getFMVPriority(ArrayRef<StringRef> Features) {
+  constexpr unsigned MaxFMVPriority = 1000;
+  unsigned Priority = 0;
+  unsigned NumFeatures = 0;
+  for (StringRef Feature : Features) {
+    if (auto Ext = parseFMVExtension(Feature)) {
+      Priority = std::max(Priority, Ext->Priority);
+      NumFeatures++;
+    }
+  }
+  return Priority + MaxFMVPriority * NumFeatures;
----------------
labrinea wrote:

You're right, that's what it does. The more specific a version is (more features), then higher its priority. If it's a tie, the version with the highest priority feature wins. Indeed this is NFC. Changing it is ABI break, which doesn't bother me personally. I think since FMV is not yet widely used, we should be free to make sensible changes to the specification.

I am not sure what the original idea was. Perhaps it makes sense a feature that depends on other features to have higher priorirty than them? We could use the runtime bitmasks for this as I tried to do here https://github.com/llvm/llvm-project/pull/87939/files#r1842027067. On a tangent, we (Arm) are discussing about potentially detecting dependent features at runtime, but that's for another time - slightly relevant though.

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


More information about the cfe-commits mailing list