[PATCH v2] Support Intel AVX10.2 media instructions

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, September 11, 2024 9:53 PM
> 

I am back with full health. Let me handle rest of them.

> On 09.09.2024 10:18, Haochen Jiang wrote:
> > Nit: I will rebase to the following Jan's patch after that patch's
> > AVX-VNNI-INT8/16 being implied by AVX10.2 part committed to trunk.
> >
> > https://sourceware.org/pipermail/binutils/2024-September/136630.html
> 
> I'm puzzled - didn't you ask that we not do this move?
> 
> > ---
> > For vnni instructions, we extended previous VEX part using %XE in
> > disassembler to promote them to EVEX.
> 
> Yet this doesn't look to be exercised anywhere in the testcases.
> 

Should I add some tests like {evex} vpdpbssd to make this clear?

> 
> I'm afraid I don't understand this. Why can't you use %XE in the new table
> entry? (Of course you can't simply re-use the original one.)
> 
> > For assmbler part, we put the vnni table entries with previous vnni
> > instructions since most of them
> 
> Right, that's why I made the templates for them to (also) use.
> 
> Related to this placement: Did you notice the resulting anomaly in encodings
> used? Without resorting to knowledge of the internal workings of gas, what
> would you predict this
> 
> 	vpdpbssd	%xmm1, %xmm2, %xmm3
> 	vpdpbusd	%xmm1, %xmm2, %xmm3
> 	vpdpwssd	%xmm1, %xmm2, %xmm3
> 	vpdpwusd	%xmm1, %xmm2, %xmm3
> 
> assembles to (VEX vs EVEX) with your patch in place? And then the same with
> e.g.
> 
> 	.arch generic64
> 	.arch .avx10.2/256
> 
> in place ahead of the block. The patch of mine you reference above is related
> to this, but it doesn't fully resolve the anomaly. I'm still trying to think of a
> good solution. My expectation certainly would be that the latest with the
> AVX10.2 forms added, the VEX forms would be used by default everywhere,
> as that's the usual EVEX-postdates-VEX situation. Yet part of that would be
> that AVX-VNNI{,-INT8,-INT16} were formal prereqs of AVX10.2 (hence in turn
> that earlier patch, as a first step in that direction).

That is why I am ok with part of the mentioned patch. I suppose AVX10.2 should
imply AVX-VNNI-INT8/16 here.

> 
> 
> > are just promotion from AVX-VNNI-INT{8,16}.
> >[...]
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/avx10_2-256-1-intel.d
> > @@ -0,0 +1,151 @@
> > +#objdump: -dw -Mintel
> > +#name: i386 AVX10.2/256 media insns (Intel disassembly)
> > +#source: avx10_2-256-1.s
> > +
> > +.*: +file format .*
> > +
> > +Disassembly of section \.text:
> > +
> > +0+ <_start>:
> > +#...
> > +\s*416:\s*62 f2 57 2f 50 f4\s+vpdpbssd ymm6\{k7\},ymm5,ymm4
> 
> I guess I can see why you don't use [a-f0-9]+ here, but no, that's not nice.
> How about you add a label ahead of the Intel syntax block, and then use that
> as "anchor"? (Similarly applicable to other tests
> then.)
> 

I will add a label for that. Also for the previous ymm rounding test, with a separate
patch.

Also I will re-do the table part. Never do something when feeling not well or it will be
a total mess.

Thx,
Haochen

> 
> Jan