Re: [PATCH] x86: fold AVX512-VNNI disassembler entries with AVX-VNNI ones

[Jan Beulich <jbeulich@suse.com>]

On 17.10.2022 23:10, H.J. Lu wrote:
> On Sun, Oct 16, 2022 at 11:39 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.10.2022 19:28, H.J. Lu wrote:
>>> On Fri, Oct 14, 2022 at 3:22 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> Make %XV also print the separating blank in the VEX case, while making
>>>> it do nothing for EVEX-encoded insns. This way the AVX-VNNI entries
>>>> can be re-used for AVX512-VNNI, at the same time fixing the lack of
>>>> EVEX.W decoding.
>>>>
>>>> For the AVX-VNNI ones further make sure only VEX.66 forms are actually
>>>> decoded.
>>>> ---
>>>> Irrespective of this change I continue to disagree with the arbitrary
>>>> printing of "{vex}" for the AVX-VNNI insns: If that's meant for
>>>> disambiguation purposes, then EVEX-encoded insns not using EVEX-specific
>>>> functionality by having VEX counterparts (vaddps %xmm0, %xmm0, %xmm0)
>>>> should also be prefixed by "{evex}".
>>>
>>> This is done to match the assembler.  There are 3 kinds of VNNI processors:
>>>
>>> 1. AVX512-VNNI only.
>>> 2. AVX-VNNI only.
>>> 3. AVX512-VNNI and AVX-VNNI.
>>>
>>> Since AVX512-VNNI came out first, all VNNI instructions without a prefix
>>> are encoded as AVX512-VNNI.  The existing VNNI instructions without
>>> a prefix, generated by compiler or hand written, are encoded with EVEX.
>>> If one needs VNNI with VEX encoding, the {vex} prefix should be used.
>>
>> ... if, as said, AVX512 wasn't turned off altogether.
>>
>> With your model, just look at how odd code using both AVX-VNNI and
>> AVX-VNNI-INT8 then looks:
>>
>>         vpdpbssd        %ymm0, %ymm5, %ymm6
>>         vpdpbsud        %ymm1, %ymm5, %ymm6
>>         {vex} vpdpbusd  %ymm2, %ymm5, %ymm6
>>         vpdpbuud        %ymm3, %ymm5, %ymm6
>>
>> Yes, one could further clutter this and add {vex} to every line. But
>> why would anyone want to clutter their code?
> 
> This ensures that VNNI instructions without a prefix are encoded
> with EVEX.

As does ".arch .noavx512f".

>> Plus the same argument then applies to AVX512VL: This came out later than
>> AVX, and the assembler (necessarily) requires {evex} to actually encode
>> these (when there are AVX equivalents). Hence to match the assembler, the
>> disassembler then also ought to emit {evex} for this subset of encodings.
> 
> A patch is welcome.

Will add to my list. That'll be a huge patch, I guess, because of the
sometimes excessive testcases that were added for the various sub-features.

Jan