Re: [PATCH 5/5] x86: support AVX10.1 vector size restrictions

[Jan Beulich <jbeulich@suse.com>]

On 29.08.2023 18:26, H.J. Lu wrote:
> On Fri, Aug 25, 2023 at 5:48 AM Jan Beulich <jbeulich@suse.com> wrote:
>> @@ -1673,6 +1680,12 @@ an unconditional jump to the target.
>>
>>  Note that the sub-architecture specifiers (starting with a dot) can be prefixed
>>  with @code{no} to revoke the respective (and any dependent) functionality.
>> +Note further that @samp{.avx10.<N>} can be suffixed with a vector length
>> +restriction (@samp{/256} or @samp{/128}, with @samp{/512} simply restoring the
>> +default).  Despite these otherwise being "enabling" specifiers, using these
>> +suffixes will disable all insns with wider vector or mask register operands.
>> +On SVR4-derived platforms, the separator character @samp{/} can be replaced by
>> +@samp{:}.
>>
>>  Following the CPU architecture (but not a sub-architecture, which are those
>>  starting with a dot), you may specify @samp{jumps} or @samp{nojumps} to
> 
> Although CPUID bits in AVX10 spec may leave an impression that 128-bit,
> 256-bit and 512-bit vectors may be enabled independently.  But it also says
> 
> A “converged” version of Intel AVX10 with maximum vector lengths of 256
> bits and 32-bit opmask registers will be supported across all Intel processors,
> while 512-bit vector registers and 64-bit opmasks will continue to be supported
> on some P-core processors.
> 
> Adding avx10.1/128 isn't necessary.

I agree it isn't necessary, but as expressed before I view it as desirable.
Apart from the sentence you quoted the spec later also says "There are
currently no plans to support an Intel AVX10/128 implementation." For my
choice of also supporting the 128-bit restriction I'd like to put emphasis
on "currently". I think I said before that emulation environments (qemu,
sde to name just two well-known examples) are free to implement such
further restricted ISAs without then becoming out-of-spec.

Plus supporting this mode right away has made me make certain adjustments
in what I'd call more clean a way, which I view as desirable as well.

Jan