x86: Support Intel AVX VNNI

[H.J. Lu]

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)

-- 
H.J.