x86: Support Intel AVX VNNI

[Jan Beulich]

On 19.10.2020 16:21, H.J. Lu wrote:
> On Mon, Oct 19, 2020 at 7:11 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 19.10.2020 15:43, H.J. Lu wrote:
>>> On Mon, Oct 19, 2020 at 6:40 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> 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?
>>>>
>>>
>>> vaddps %xmm0, %xmm1, %xmm2
>>>
>>> is EVEX.
>>>
>>> {vex3}/{vex} vaddps %xmm0, %xmm1, %xmm2
>>>
>>> is VEX.
>>
>> But that's not what the disassmebler produces, nor what it
> 
> This is what GDB shows in assembly source.

The %VX prefix was introduced only with the patch we're discussing
here, iirc - how would ordinary AVX insns like vaddps have gained
these undue prefixes? And if you truly mean "assembly sources"
(which isn't what we've been discussing, or at least which isn't
what I had been talking about), then wouldn't gdb show whatever
there was in the sources, without adding or removing any prefixes?

Jan