On Mon, Nov 13, 2023 at 7:25 PM Richard Biener <richard.guent...@gmail.com> wrote: > > On Mon, Nov 13, 2023 at 7:58 AM Hongtao Liu <crazy...@gmail.com> wrote: > > > > On Fri, Nov 10, 2023 at 6:15 PM Richard Biener > > <richard.guent...@gmail.com> wrote: > > > > > > On Fri, Nov 10, 2023 at 2:42 AM Haochen Jiang <haochen.ji...@intel.com> > > > wrote: > > > > > > > > Hi all, > > > > > > > > This RFC patch aims to add AVX10.1 options. After we added > > > > -m[no-]evex512 > > > > support, it makes a lot easier to add them comparing to the August > > > > version. > > > > Detail for AVX10 is shown below: > > > > > > > > Intel Advanced Vector Extensions 10 (Intel AVX10) Architecture > > > > Specification > > > > It describes the Intel Advanced Vector Extensions 10 Instruction Set > > > > Architecture. > > > > https://cdrdv2.intel.com/v1/dl/getContent/784267 > > > > > > > > The Converged Vector ISA: Intel Advanced Vector Extensions 10 Technical > > > > Paper > > > > It provides introductory information regarding the converged vector > > > > ISA: Intel > > > > Advanced Vector Extensions 10. > > > > https://cdrdv2.intel.com/v1/dl/getContent/784343 > > > > > > > > Our proposal is to take AVX10.1-256 and AVX10.1-512 as two "virtual" > > > > ISAs in > > > > the compiler. AVX10.1-512 will imply AVX10.1-256. They will not enable > > > > anything at first. At the end of the option handling, we will check > > > > whether > > > > the two bits are set. If AVX10.1-256 is set, we will set the AVX512 > > > > related > > > > ISA bits. AVX10.1-512 will further set EVEX512 ISA bit. > > > > > > > > It means that AVX10 options will be separated from the existing AVX512 > > > > and the > > > > newly added -m[no-]evex512 options. AVX10 and AVX512 options will > > > > control > > > > (enable/disable/set vector size) the AVX512 features underneath > > > > independently. > > > > If there’s potential overlap or conflict between AVX10 and AVX512 > > > > options, > > > > some rules are provided to define the behavior, which will be described > > > > below. > > > > > > > > avx10.1 option will be provided as an alias of avx10.1-256. > > > > > > > > In the future, the AVX10 options will imply like this: > > > > > > > > AVX10.1-256 <---- AVX10.1-512 > > > > ^ ^ > > > > | | > > > > > > > > AVX10.2-256 <---- AVX10.2-512 > > > > ^ ^ > > > > | | > > > > > > > > AVX10.3-256 <---- AVX10.3-512 > > > > ^ ^ > > > > | | > > > > > > > > Each of them will have its own option to enable/disabled corresponding > > > > features. The alias avx10.x will also be provided. > > > > > > > > As mentioned in August version RFC, since we lean towards the adoption > > > > of > > > > AVX10 instead of AVX512 from now on, we don’t recommend users to > > > > combine the > > > > AVX10 and legacy AVX512 options. > > > > > > 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. > > Richard. > > > > > > > > However, we would like to introduce some > > > > simple rules for user when it comes to combination. > > > > > > > > 1. Enabling AVX10 and AVX512 at the same command line with different > > > > vector > > > > size will lead to a warning message. The behavior of the compiler will > > > > be > > > > enabling AVX10 with longer, i.e., 512 bit vector size. > > > > > > > > If the vector sizes are the same (e.g. -mavx10.1-256 -mavx512f > > > > -mno-evex512, > > > > -mavx10.1-512 -mavx512f), it will be valid with the corresponding > > > > vector size. > > > > > > > > 2. -mno-avx10.1 option can’t disable any features enabled by AVX512 > > > > options or > > > > impact the vector size, and vice versa. The compiler will emit warnings > > > > if > > > > necessary. > > > > > > > > For the auto dispatch support including function multi versioning, > > > > function > > > > attribute usage, the behavior will be identical to compiler options. > > > > > > > > If you have any questions, feel free to ask in this thread. > > > > > > > > Thx, > > > > Haochen > > > > > > > > > > > > > > > > -- > > BR, > > Hongtao
-- BR, Hongtao
