[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