x86: Support Intel AVX VNNI

[Jan Beulich]

On 19.10.2020 15:37, H.J. Lu wrote:
> On Mon, Oct 19, 2020 at 6:22 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 19.10.2020 14:24, H.J. Lu wrote:
>>> On Sun, Oct 18, 2020 at 11:28 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 16.10.2020 20:07, H.J. Lu wrote:
>>>>> When AVX VNNI was added, we could either use different mnemonics
>>>>> from AVX512 VNNI or a {vex} prefix.  We went with {vex} and made it
>>>>> mandatory to avoid any confusion.
>>>>
>>>> What confusion could there be when a person has given suitable
>>>> explicit .arch directives? And how is {vex3} in disassembler
>>>
>>> When debugging assembly codes under GDB, one shouldn't guess
>>> how they are assembled.
>>
>> And in gdb how do you tell
>>
>>         vaddps %xmm0, %xmm1, %xmm2
>>
>> from
>>
>>         {evex} vaddps %xmm0, %xmm1, %xmm2
>>
>> or
>>
>>         {vex3} vaddps %xmm0, %xmm1, %xmm2
>>
>> This is exactly the same as the case at hand, just that the
>> order in time in which both encodings where introduced is
>> reversed. But the order of introduction time shouldn't matter
>> to the (long term) behavior of a tool.
> 
> When assembly sources are assembled with -g, one can
> debug assembly codes in GDB like C:
> 
> Breakpoint 1, __memcmp_avx2_movbe ()
>     at ../sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S:64
> 64 movl %edx, %edx
> (gdb) list
> 59 ENTRY (MEMCMP)
> 60 # ifdef USE_AS_WMEMCMP
> 61 shl $2, %RDX_LP
> 62 # elif defined __ILP32__
> 63 /* Clear the upper 32 bits.  */
> 64 movl %edx, %edx
> 65 # endif
> 66 cmp $VEC_SIZE, %RDX_LP
> 67 jb L(less_vec)
> 68
> (gdb)

I know, but how is this related to what I've said?

Jan