android-riscv64
android-riscv64 copied to clipboard
google
llvm function multi-versioning
related to but distinct from https://github.com/google/android-riscv64/issues/8, we'll want function multi-versioning in llvm.
Is this issue related to the multi-versioning feature itself or to function optimization that supports different instruction set extensions?
Is this issue related to the multi-versioning feature itself or to function optimization that supports different instruction set extensions?
the former --- we don't expect this to be useful for OS developers, but -- especially because riscv64 might unfortuntely end up more fragmented than other architectures in the long term -- this might be helpful for third-party library/app developers. (our experience with the existing architectures is that ifuncs are too much trouble for all but the absolute most performance-conscious. we hope -- but don't know yet, because llvm's fmv functionality for arm64 is too new, and no developers really care about x86-64 -- that fmv will help.)
ifuncs are too much trouble [...] fmv will help
To the best of my knowledge, function multiversioning in both LLVM and GCC is implemented using GNU indirect functions. So this ticket could be considered blocked on #8.
This is referring something like this? https://gcc.gnu.org/wiki/FunctionMultiVersioning
Yes. As usual, @maskray's blog has useful info: https://maskray.me/blog/2023-02-05-function-multi-versioning
(fwiw, in terms of prioritization -- which i know is on everyone's minds right now -- i think fmv is a thing for after you have an ecosystem, and you're starting to see fragmentation in terms of extension availability, and how you can help bring the cost of dealing with that down for app developers. because otherwise the traditional default is "target the lowest available [since i have to support that anyway], leave any extra performance lying on the table [because i can't afford the extra development or testing costs]". fmv doesn't help with the testing costs -- which are admittedly the dominating factor for all developers -- but it does at least bring the development costs way down relative to ifuncs or messing around with cpu feature detection directly. x86-64 has had this for a long time, but arm64 only just gained it. riscv64 can probably punt this to the late 2020s, but it's on the list for feature parity.)
Kito filed an issue here https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35
