RE: Intel AVX10.1 Compiler Design and Support

["Zhang, Annita" <annita.zhang@intel.com>]

> -----Original Message-----
> From: Florian Weimer <fweimer@redhat.com>
> Sent: Wednesday, August 9, 2023 5:16 PM
> To: Hongtao Liu <crazylht@gmail.com>
> Cc: Beulich, Jan <JBeulich@suse.com>; Jiang, Haochen
> <haochen.jiang@intel.com>; gcc-patches@gcc.gnu.org; ubizjak@gmail.com;
> Liu, Hongtao <hongtao.liu@intel.com>; Zhang, Annita
> <annita.zhang@intel.com>; Wang, Phoebe <phoebe.wang@intel.com>; x86-
> 64-abi <x86-64-abi@googlegroups.com>; llvm-dev <llvm-dev@lists.llvm.org>;
> Craig Topper <craig.topper@gmail.com>; Joseph Myers
> <joseph@codesourcery.com>
> Subject: Re: Intel AVX10.1 Compiler Design and Support
> 
> * Hongtao Liu:
> 
> > On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich <jbeulich@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