x86: Support Intel AVX VNNI

[Jan Beulich]

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
should produce. There's no need for {vex} on the assembler
side (as encoding defaults to the VEX variant for all AVX
and AVX2 insns), and hence the disassembler also doesn't
(and shouldn't) output {vex}. If anything, in an extended
mode, {vex3} / {evex} could be produced for insns where
multiple encodings are possible, to disambiguate them.

Jan