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

[Richard Biener <richard.guenther@gmail.com>]

On Fri, Nov 10, 2023 at 2:42 AM Haochen Jiang <haochen.jiang@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,
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).

> 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
>
>