> -----Original Message----- > From: Florian Weimer <fwei...@redhat.com> > Sent: Wednesday, August 9, 2023 5:16 PM > To: Hongtao Liu <crazy...@gmail.com> > Cc: Beulich, Jan <jbeul...@suse.com>; Jiang, Haochen > <haochen.ji...@intel.com>; gcc-patches@gcc.gnu.org; ubiz...@gmail.com; > Liu, Hongtao <hongtao....@intel.com>; Zhang, Annita > <annita.zh...@intel.com>; Wang, Phoebe <phoebe.w...@intel.com>; x86- > 64-abi <x86-64-...@googlegroups.com>; llvm-dev <llvm-...@lists.llvm.org>; > Craig Topper <craig.top...@gmail.com>; Joseph Myers > <jos...@codesourcery.com> > Subject: Re: Intel AVX10.1 Compiler Design and Support > > * 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
Since 256bit and 512bit are diverged from AVX10.1 and will continue in the future AVX10 versions, I think it's hard to keep a single version number to cover both and increase monotonically. Hence I'd like to suggest x86-64-v5 for 512bit and x86-64-v5-256 for 256bit, and so on. Thx, Annita
