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

[Jan Beulich <jbeulich@suse.com>]

On 30.08.2023 17:25, H.J. Lu wrote:
> On Wed, Aug 30, 2023 at 12:57 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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.
> 
> Since AVX10 spec doesn't specify if mask registers should be limited to
> 16 bits for AVX10/128, doing it in assembler is premature.

It's hard to see why they would remain wider. The more that they were 16
bits only in AVX512F.

Plus of course nobody needs to use the options to enforce the 128-bit
limit. The way I've coded it, it matches what the specification says.

Jan