On Wed, Aug 9, 2023 at 5:15 PM Florian Weimer <fwei...@redhat.com> wrote: > > * 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. Not only 16-bit floating point, here's a whole picture of AVX512->AVX10 in Figure 1-1. Intel® AVX-512 Feature Flags Across Intel® Xeon® Processor Generations vs. Intel® AVX10 and Figure 1-2. Intel® ISA Families and Features at https://cdrdv2.intel.com/v1/dl/getContent/784343 (this link is a direct download of pdf).
> > (The thread subject is a bit misleading for this sub-topic, by the way.) > > Thanks, > Florian > -- BR, Hongtao
