RE: Intel AVX10.1 Compiler Design and Support

[Zhang, Annita via Gcc-patches]

> -----Original Message-----
> From: Michael Matz <m...@suse.de>
> Sent: Wednesday, August 9, 2023 9:54 PM
> To: Zhang, Annita <annita.zh...@intel.com>
> Cc: Florian Weimer <fwei...@redhat.com>; Hongtao Liu
> <crazy...@gmail.com>; Beulich, Jan <jbeul...@suse.com>; Jiang, Haochen
> <haochen.ji...@intel.com>; gcc-patches@gcc.gnu.org; ubiz...@gmail.com;
> Liu, Hongtao <hongtao....@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
> 
> Hello,
> 
> On Wed, 9 Aug 2023, Zhang, Annita via Gcc-patches wrote:
> 
> > > 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.
> 
> The raison d'etre for the x86-64-vX scheme is to make life sensible as
> distributor.  That goal can only be achieved if this scheme contains only a 
> few
> components that have a simple relationship.  That basically means:
> one dimension only.  If you now add a second dimension (with and without
> -512) we have to add another one if Intel (or whomever else) next does a
> marketing stunt for feature "foobar" and end up with x86-64-v6, x86-64-v6-
> 512, x86-64-v6-1024, x86-64-v6-foobar, x86-64-v6-512-foobar, x86-64-v6-
> 1024-foobar.
> 
> In short: no.
> 
> It isn't the right time anyway to assign meaning to x86-64-v5, as it wasn't 
> the
> right time for assigning x86-64-v4 (as we now see).  These are supposed to
> reflect generally useful feature sets actually shipped in generally available 
> CPUs
> in the market, and be vendor independend.  As such it's much too early to
> define v5 based purely on text documents.
> 
> 
> Ciao,
> Michael.

Make sense.