This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: Set Vex=1 on VEX.128 only vmovq
On Sun, Sep 16, 2018 at 5:18 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Sep 16, 2018 at 1:37 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>> "H.J. Lu" <hjl.tools@gmail.com> 09/15/18 11:54 PM >>>
>>>AVX "VMOVQ xmm1, xmm2/m64" and "VMOVQ xmm1/m64, xmm2" can only be
>>>encoded with VEX.128. Set Vex=1 on VEX.128 only vmovq and update
>>>assembler tests.
>>
>> Indeed, but ...
>>
>>
>>>--- a/opcodes/i386-opc.tbl
>>>+++ b/opcodes/i386-opc.tbl
>>>@@ -2030,8 +2030,8 @@ vmovntdq, 2, 0x66e7, None, 1, CpuAVX, Modrm|Vex|VexOpcode=0|VexW=3|CheckRegSize|
>>>vmovntdqa, 2, 0x662a, None, 1, CpuAVX, Modrm|Vex|VexOpcode=1|VexW=3|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Xmmword|Unspecified|BaseIndex, RegXMM }
>> >vmovntpd, 2, 0x662b, None, 1, CpuAVX, Modrm|Vex|VexOpcode=0|VexW=3|CheckRegSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM|RegYMM, Xmmword|Ymmword|Unspecified|BaseIndex }
>>>vmovntps, 2, 0x2b, None, 1, CpuAVX, Modrm|Vex|VexOpcode=0|VexW=3|CheckRegSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM|RegYMM, Xmmword|Ymmword|Unspecified|BaseIndex }
>>>-vmovq, 2, 0xf37e, None, 1, CpuAVX, Load|Modrm|Vex=3|VexOpcode=0|VexW=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|NoRex64, { Qword|Unspecified|BaseIndex|RegXMM, RegXMM }
>>>-vmovq, 2, 0x66d6, None, 1, CpuAVX, Modrm|Vex=3|VexOpcode=0|VexW=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|NoRex64, { RegXMM, Qword|Unspecified|BaseIndex|RegXMM }
>>>+vmovq, 2, 0xf37e, None, 1, CpuAVX, Load|Modrm|Vex=1|VexOpcode=0|VexW=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|NoRex64, { Qword|Unspecified|BaseIndex|RegXMM, RegXMM }
>>>+vmovq, 2, 0x66d6, None, 1, CpuAVX, Modrm|Vex=1|VexOpcode=0|VexW=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|NoRex64, { RegXMM, Qword|Unspecified|BaseIndex|RegXMM }
>>>vmovq, 2, 0x666e, None, 1, CpuAVX|Cpu64, D|Modrm|Vex=3|VexOpcode=0|VexW=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Size64, { Reg64|Unspecified|BaseIndex, RegXMM }
>>>vmovsd, 2, 0xf210, None, 1, CpuAVX, D|Modrm|Vex=3|VexOpcode=0|VexW=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Qword|Unspecified|BaseIndex, RegXMM }
>>>vmovsd, 3, 0xf210, None, 1, CpuAVX, D|Modrm|Vex=3|VexOpcode=0|VexVVVV=1|VexW=3|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM|RegMem, RegXMM, RegXMM }
>>
>> ... you then also ought to change the respective SSE2AVX movq instances (one of the
It fixed on users/hjl/wig branch.
>> undesirable side effects of these requiring separate templates). Furthermore their AVX512
>> counterparts appear to have the same issue, using Evex=4 currently instead of Evex=2.
>> And yet further, the other encodings (with the 32-bit variants named VMOVD) all look to
>> have the same issue as well.
>
> I will check.
I opened:
https://sourceware.org/bugzilla/show_bug.cgi?id=23670
--
H.J.