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

[Piyou Chen via cfe-commits]

================
@@ -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);
----------------
BeMg wrote:

My concern is that `RISCVTargetInfo::getFMVPriority` needs to retrieve `Features[0]` for processing. If we modified the function signature to `RISCVTargetInfo::getFMVPriority(ArrayRef<StringRef> Features, ArrayRef<StringRef> Architecture)`, it would help avoid unclear access behavior.

```
unsigned RISCVTargetInfo::getFMVPriority(ArrayRef<StringRef> Features) const {
  SmallVector<StringRef, 8> Attrs;
  Features[0].split(Attrs, ';');
```

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