* Hongtao Liu: > On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich <jbeul...@suse.com> wrote: >> Aiui these ABI levels were intended to be incremental, i.e. higher versions >> would include everything earlier ones cover. Without such a guarantee, how >> would you propose compatibility checks to be implemented in a way
Correct, this was the intent. But it's mostly to foster adoption and make it easier for developers to pick the variants that they want to target custom builds. If it's an ascending chain, the trade-offs are simpler. > Are there many software implemenation based on this assumption? > At least in GCC, it's not a big problem, we can adjust code for the > new micro-architecture level. The glibc framework can deal with alternate choices in principle, although I'd prefer not to go there for the reasons indicated. >> applicable both forwards and backwards? If a new level is wanted here, then >> I guess it could only be something like v3.5. > But if we use avx10.1 as v3.5, it's still not subset of > x86-64-v4(avx10.1 contains avx512fp16,avx512bf16 .etc which are not in > x86-64-v4), there will be still a diverge. > Then 256-bit of x86-64-v4 as v3.5? that's too weired to me. The question is whether you want to mandate the 16-bit floating point extensions. You might get better adoption if you stay compatible with shipping CPUs. Furthermore, the 256-bit tuning apparently benefits current Intel CPUs, even though they can do 512-bit vectors. (The thread subject is a bit misleading for this sub-topic, by the way.) Thanks, Florian
