Background
In thread [RFC] Design for AVX10 feature support, we discussed proposals to support AVX10 feature and implemented a fake EVEX512 feature and its options. With the new option, the built binaries can be run on both legacy AVX512 targets and AVX10.
In this thread, I will discuss how AVX512XXX and EVEX512 features become obstacles when we are going to support AVX10, propose the way to support AVX10.1 options and introduce how we solve the problems.
Proposal for AVX10 options
We won’t provide a separate vector control feature/option for AVX10, instead, we will only provide -mavx10.x-256 and -mavx10.x-512. A -mavx10.x is provided as an alias to -mavx10.x-256.
We avoid to use separate vector control feature/option, because it cannot be used for target clone. E.g. In
int __attribute__((target_clones("avx2","default","avx10.1,avx10-512bit")))
foo() {
return 1;
}
A "avx10.1,avx10-512bit" will be split into a avx10.1 target and a avx10-512bit target. We cannot represent a AVX10 512-bit target in a combination of vector size and avx10.1 but a integrated avx10.1-512.
Introduce a new -mavx10-512bit option will also confuse user with the prior -mevex512 option. OTOH, evex512 as a fake feature cannot be used for AVX10 either, since AVX10 needs a real feature for dispatching in FMV. Besides, using evex512 for AVX10 could also result in ambiguity.
Ambiguities in options’ combination
We design EVEX512 a default by on feature when AVX512 features are set. That says the -mavx512xxx options don’t imply vector size control, so a -mno-evex512 -mavx512bw equals to -mavx512bw -mno-evex512. In a word, a -mavx512bw won’t override vector size to 512-bit.
The problem is the size suffix -256/512 in AVX10 options specifies the vector size. It’s counterintuitive if a avx10.1-512 cannot override vector size to 512-bit in the combination -mno-evex512 -mavx10.1-512. However, the different effects between AVX512XXX and AVX10.X brings more confusions that it solves.
The combination between AVX512XXX and AVX10.X has the same problem due to EVEX512 is on by default for AVX512XXX.
Other than that, the combination between AVX512XXX and AVX10.X is also meaningless. An AVX10.x-512 feature always implies AVX512XXX features, while specifying an exclusive AVX512 feature like AVX512-VP2INTERSECT for a AVX10 512-bit target or any AVX512 features for a AVX10 256-bit target will result in the binary cannot run on any targets.
Stop to use AVX512XXX or EXEV512 with AVX10 options
To solve ambiguities in options’ combination, we will emit warning in driver to remind user not to do so. Any AVX512XXX or EXEV512 options will be ignored when they are used with AVX10 options.
Proposal for AVX10.1
We still use EVEX512 internally for AVX10.1. We make AVX10.1-256 imply all related AVX512 features, while set NO-EVEX512 explicitly. While AVX10.1-512 only implies AVX10.1-256 and EVEX512.
Here is the RFC patch: [X86][RFC] Support AVX10 options by phoebewang · Pull Request #67278 · llvm/llvm-project · GitHub