[clang] [FMV][AArch64][clang] Emit fmv-features metadata in LLVM IR. (PR #118544)

[Jon Roelofs via cfe-commits]

jroelofs wrote:

> > A motivating example might be target_version("simd+dotprod") and target_version("sve"): when sve is available we should pick that version, but the current rule prioritizes the number of attribute-specified features over their overall weight.
> 
> I agree about this. As I said we will adress the priorities and selection algorithm separately.
> 
> > I think if we fix that rule, and instead sort priorities lexicographically after adding implicit features implied by command-line options, then this change becomes unnecessary
> 
> The lexicographic ordering discards the ACLE priorities. I don't think it's what we want here.

I should clarify that I mean: take the listed features for a given function, sort them according to their priorities highest to lowest as if each priority were a letter in a `${highest_priority+1}` sized alphabet and the whole set of priorities for a function comprised a word made up of those letters, and then sort those words lexicographically with ties broken in favor of word length.

Consider a multi-versioned function with `simd+dotprod`, `simd`, `sve`, and `default`:

 * `simd+dotprod` has "letters" `{100, 104}`. Sorted, that's `{104, 100}`.
 * `simd` has one "letter" `{100}`
 * `sve` has one "letter" `{310}`
 * `default` has no "letters" `{}`
 
 Now with those sorted according to that lexicographic order, we have a total order for the set:
 
 `default` < `simd` < `simd+dotprod` < `sve`

The selection process then filters out elements that cannot be chosen per runtime availability of features, and selects the remaining choice that is "greatest" according to that order.

>  I am not sure how I feel about mixing the features inherited from the cmdline option with the fmv features. If we do that we should be detecting them at runtime if we want the static resolution optimization to behave the same as the resolver. However, making the version selection not only depend on the source code but also the cmdline may not be the right thing to do.

The way I see it, setting command-line options sets the floor for minimum feature set: one cannot expect to run code on a machine that does not at least meet that minimum. Because of that assumption, every version in the multi-version set inherits those implicit features. Imagine a multi-versioned function with three implementations: `sha2`, `sha2+sha3`, `default`. Compiled with `-mcpu=generic`, we'd get the usual behavior. Compiled with `-mcpu=generic+sha2`, the `default` implementation will never be called, and runtime selection will only need to decide between the version with/without `sha3`. Likewise, compiling with `-mcpu=generic+sha3` will guarantee that both `sha2` and `sha3` are present in the feature set, as the former is implied by the latter in the `ExtensionWithMArch` sense, and thus the `sha2+sha3` implementation is the only one that matters.

Do you have a case in mind where this would behave differently than the runtime resolver? I suppose we should distinguish two cases: both with the current sorting rule, and with that lexicographic-ish rule I'm proposing.



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