x86: Support Intel AVX VNNI

Jan Beulich jbeulich@suse.com
Mon Oct 19 11:19:39 GMT 2020


On 19.10.2020 10:26, Cui, Lili 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 output helping in
>> any way, when comparing to all other AVX+ insns which have AVX512VL
>> counterparts? (Apart from that I'd further question why it needs to be {vex3}
>> when {vex} would suffice, but I'd like to see this dropped altogether anyway,
>> except perhaps in some non-default mode, where it then should be output
>> consistently.)
> 
> About " why it needs to be {vex3} when {vex} would suffice ", I think AVX_VNNI  can
> not be expressed in {vex} format, because all AVX_VNNI instructions need the bitfield  
> "m-mmmm" of {vex3} to express 0F38, thanks.

{vex} doesn't mean "2-byte VEX", but "either form of VEX". All
it precludes is legacy or EVEX encoding. {vex2} was deprecated
because where possible gas will pick the 2-byte encoding anyway
(and iirc {vex2} also mistakenly had [almost] the meaning of
{vex}).

Jan


More information about the Binutils mailing list