[PATCH 0/5] x86/Intel: AVX512 syntax enhancements

[Jan Beulich]

On 10.05.2022 04:37, Cui, Lili wrote:
> 
>> -----Original Message-----
>> From: Binutils <binutils-bounces+lili.cui=intel.com@sourceware.org> On
>> Behalf Of Jan Beulich via Binutils
>> Sent: Wednesday, May 4, 2022 7:45 PM
>> To: Binutils <binutils@sourceware.org>
>> Subject: [PATCH 0/5] x86/Intel: AVX512 syntax enhancements
>>
>> As pointed out long ago already, what gas accepts and what objdump emits
>> isn't in line with the SDM. Finally I also happened to find mention of this in
>> MASM documentation [1]. This series extends (gas) and converts (objdump)
>> respective support. As a nice side effect, a few hundred insn templates go
>> away from the opcode table.
>>
>> 1: Intel: adjust representation of embedded broadcast
>> 2: Intel: allow MASM representation of embedded broadcast
>> 3: Intel: adjust representation of embedded rounding / SAE
>> 4: re-work AVX512 embedded rounding / SAE
>> 5: Intel: allow MASM representation of embedded rounding / SAE
>>
> 
> Hi Jan, 
> I reviewed all the patches in this patch set,

Thanks.

> I have only one doubt, the others look good.
> 
> 1. If we use BCST instead {1to*}, it cannot directly reflect the broadcast number. When the register size is zmm, but broadcast number is not the same.
> 
> -[      ]*[a-f0-9]+:[   ]*62 f5 54 58 58 31[     ]*vaddph zmm6,zmm5,WORD PTR \[ecx\]\{1to32\}
> +[      ]*[a-f0-9]+:[   ]*62 f5 54 58 58 31[     ]*vaddph zmm6,zmm5,WORD BCST \[ecx\]
> 
> -[      ]*[a-f0-9]+:[   ]*62 65 7d df 5b 72 80[          ]*vcvtph2dq zmm30\{k7\}\{z\},WORD PTR \[rdx-0x100\]\{1to16\}
> +[      ]*[a-f0-9]+:[   ]*62 65 7d df 5b 72 80[          ]*vcvtph2dq zmm30\{k7\}\{z\},WORD BCST \[rdx-0x100\]

This case is clearly disambiguated by the destination register.
What I think you're worried about are conversions where the
field size shrinks (e.g. from 32 bits to 16 bits, like in
vcvtdq2ph). In this case you will note that for the purpose of
keeping things unambiguous the disassembler will continue to
emit {1to<N>}, and the assembler will continue to require that
extra bit of information.

> 2. Just remove the last comma, it's ok for me, I remember FP16 has an instruction with {sae} on the middle position for the ATT format. But the intel format is placed at the end, I don't know if there is any problem.
> 
> -[      ]*[a-f0-9]+:[   ]*62 f5 54 18 58 f4[     ]*vaddph zmm6,zmm5,zmm4,\{rn-sae\}
> +[      ]*[a-f0-9]+:[   ]*62 f5 54 18 58 f4[     ]*vaddph zmm6,zmm5,zmm4\{rn-sae\}
> 
> FP16:
> vcvtusi2sh %edx, {rn-sae}, %xmm29, %xmm30
> vcvtusi2sh xmm6,xmm5,edx\{rn-sae\}

Well, yes, this is not only not a problem, but intended. See how the
SDM places the rounding/SAE modifiers. It's also not FP16-specific
in any way.

> 3. This can reduce the  templates size, it is good to me.
> 
> -vsubsh, 0xf35c, None, CpuAVX512_FP16, Modrm|EVexLIG|Masking=3|EVexMap5|VexVVVV|VexW0|Disp8MemShift=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM|Word|Unspecified|BaseIndex, RegXMM, RegXMM }
> -vsubsh, 0xf35c, None, CpuAVX512_FP16, Modrm|EVexLIG|Masking=3|EVexMap5|VexVVVV|VexW0|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE, { Imm8, RegXMM, RegXMM, RegXMM }
> 
> +vsubsh, 0xf35c, None, CpuAVX512_FP16, Modrm|EVexLIG|Masking=3|EVexMap5|VexVVVV|VexW0|Disp8MemShift=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE, { RegXMM|Word|Unspecified|BaseIndex, RegXMM, RegXMM }

I'm afraid I don't understand what you're trying to tell me here.
Are you asking for some kind of change to be made to the patch(es)?

Jan