x86: Support Intel AVX VNNI

[H.J. Lu]

On Mon, Oct 19, 2020 at 7:55 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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?
>

I probably lost the track.   Let me rephrase it again.  The {vex}
prefix for AVX VNNI is mandatory.


-- 
H.J.