[PATCH v2] Support Intel AVX10.2 media instructions

[Jan Beulich]

On 18.09.2024 07:48, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Wednesday, September 11, 2024 9:53 PM
>>
>> 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?

Yes please.

>> 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.

And your doc folks would be willing to actually spell that out? (We're okay
without, but it would be better if it was written down.)

Jan