RE: [RFC] Intel AVX10.1 Compiler Design and Support

["Jiang, Haochen" <haochen.jiang@intel.com>]

> > > > I wonder whether adoption could be made easier by also providing a
> > > > -mavx10[.0] level that removes some of the more obscure sub-ISA
> > > > requirements to cover more existing implementations (I'd not add -mavx10.0-512 here).
> > > > I'd require only skylake-AVX512 features here, basically all
> > > > non-KNL AVX512 CPUs should have a "virtual" AVX10 level that
> > > > allows to use that feature set,
> > >
> > > We have -mno-evex512 can cover those cases, so what you want is like
> > > a simple alias of "-march=skylake-avx512 -mno-evex512"?
> >
> > For the AVX512 enabled sub-isas of skylake-avx512 yes I guess.
> >
> > > > restricted to 256bits so future AVX10-256 implementations can
> > > > handle it as well as all existing (and relevant, which excludes
> > > > KNL) AVX512 implementations.
> > > >
> > > > Otherwise AVX10 is really a hard sell (as AVX512 was originally).
> > >
> > > It's a rebranding of the existing AVX512 to AVX10, AVX10.0  just
> > > complicated things further(considering we already have x86-64-v4
> > > which is different from skylake-avx512).
> >
> > Well, the cut-off for "AVX512" is quite arbitrary.  Introducing a
> > "new" ISA that's only available in HW available in the future and
> > suggesting users to embrace that already (like Intel did with AVX512
> > without offering client SKU support) is a hard sell.
> >
> > I realize Intel thinks client SKU support for AVX10 (restricted to
> > 256bit) will be "easier".  But then don't expect anybody to adopt that in the next 10 years.
> >
> > Just to add - we were suggesting to use x86_64-v3 for the "next"
> > enterprise product but got downvoted to x86_64-v2 for compatibility reasons.
> >
> > If it were possible I'd axe x86_64-v4.  Maybe we should add a
> > x86_64-v3.5 that sits inbetween v3 and v4, offering AVX512 but
> > restricted to 256bit (and obviously not requiring more of the AVX512 features that v4 requires).
>
> About the arch level is indeed a problem, especially since the default size of
> avx10 is 256.
> +Florian Weimer for more inputs.

IMO, AVX10.1 options should be there and the arch level issue should not affect the
existence of this series of options.

The issue currently we are facing is much about the arch level issue actually since
we have defined x86-64-v4 before. The "-march=skylake-server -mno-evex512" is
much like something x86-64-v4-256.

Thx,
Haochen