[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 07:30:43 PST 2024


================
@@ -4216,22 +4216,11 @@ static void ReplaceUsesOfNonProtoTypeWithRealFunction(llvm::GlobalValue *Old,
                                                       llvm::Function *NewFn);
 
 static unsigned
-TargetMVPriority(const TargetInfo &TI,
-                 const CodeGenFunction::MultiVersionResolverOption &RO) {
-  unsigned Priority = 0;
-  unsigned NumFeatures = 0;
-  for (StringRef Feat : RO.Conditions.Features) {
-    Priority = std::max(Priority, TI.multiVersionSortPriority(Feat));
-    NumFeatures++;
-  }
-
-  if (!RO.Conditions.Architecture.empty())
-    Priority = std::max(
-        Priority, TI.multiVersionSortPriority(RO.Conditions.Architecture));
-
-  Priority += TI.multiVersionFeatureCost() * NumFeatures;
-
-  return Priority;
+getFMVPriority(const TargetInfo &TI,
+               const CodeGenFunction::MultiVersionResolverOption &RO) {
+  llvm::SmallVector<StringRef, 8> Features{RO.Conditions.Features};
+  Features.push_back(RO.Conditions.Architecture);
+  return TI.getFMVPriority(Features);
----------------
labrinea wrote:

The struct MultiVersionResolverOption was originally tailored to x86 if I am not mistaken. RO.Conditions.Architecture isn't suitable for AArch64, and correct me if I am wrong but so far it doesn't seem that risc-v is using it either? Even on x86 Architecture is treated the same as any other feature string in the existing hook multiVersionSortPriority, so I don't see the need for explicit argument.

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


More information about the cfe-commits mailing list