[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