================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
