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