* [PATCH] x86: Properly encode vmovd with 64-bit memeory
@ 2018-01-08 1:18 H.J. Lu
2018-01-08 8:48 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: H.J. Lu @ 2018-01-08 1:18 UTC (permalink / raw)
To: binutils; +Cc: Jan Beulich
For historical reason, we allow movd/vmovd with 64-bit register and
memeory operands. But for vmovd, we failed to handle 64-bit memeory
operand. This has been gone unnoticed since AT&T syntax always treats
memory operand as 32-bit memory. This patch properly encodes vmovd
with 64-bit memeory operands.
I am checking it in tomorrow.
H.J.
---
gas/
PR gas/22681
* testsuite/gas/i386/i386.exp: Run x86-64-movd and
x86-64-movd-intel.
* testsuite/gas/i386/x86-64-movd-intel.d: New file.
* testsuite/gas/i386/x86-64-movd.d: Likewise.
* testsuite/gas/i386/x86-64-movd.s: Likewise.
opcodes/
PR gas/22681
* i386-opc.tbl: Properly encode vmovd with Qword memeory operand.
* i386-tbl.h: Regenerated.
---
gas/testsuite/gas/i386/i386.exp | 2 ++
gas/testsuite/gas/i386/x86-64-movd-intel.d | 51 ++++++++++++++++++++++++++++++
gas/testsuite/gas/i386/x86-64-movd.d | 50 +++++++++++++++++++++++++++++
gas/testsuite/gas/i386/x86-64-movd.s | 45 ++++++++++++++++++++++++++
opcodes/i386-opc.tbl | 8 ++---
opcodes/i386-tbl.h | 20 ++++++------
6 files changed, 162 insertions(+), 14 deletions(-)
create mode 100644 gas/testsuite/gas/i386/x86-64-movd-intel.d
create mode 100644 gas/testsuite/gas/i386/x86-64-movd.d
create mode 100644 gas/testsuite/gas/i386/x86-64-movd.s
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 3fd0e4633d..20bcf91823 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -900,6 +900,8 @@ if [expr ([istarget "i*86-*-*"] || [istarget "x86_64-*-*"]) && [gas_64_check]] t
run_dump_test "x86-64-notrack"
run_dump_test "x86-64-notrack-intel"
run_list_test "x86-64-notrackbad" "-al"
+ run_dump_test "x86-64-movd"
+ run_dump_test "x86-64-movd-intel"
if { ![istarget "*-*-aix*"]
&& ![istarget "*-*-beos*"]
diff --git a/gas/testsuite/gas/i386/x86-64-movd-intel.d b/gas/testsuite/gas/i386/x86-64-movd-intel.d
new file mode 100644
index 0000000000..65600857ce
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-movd-intel.d
@@ -0,0 +1,51 @@
+#source: x86-64-movd.s
+#as: -J
+#objdump: -dw -Mintel
+#name: x86-64 movd (Intel mode)
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+ <_start>:
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 66 48 0f 6e c8 movq xmm1,rax
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 48 0f 7e c8 movq rax,xmm1
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: c4 e1 f9 6e c8 vmovq xmm1,rax
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: c4 e1 f9 7e c8 vmovq rax,xmm1
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 66 0f 6e c8 movd xmm1,eax
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 0f 7e c8 movd eax,xmm1
+ +[a-f0-9]+: 66 48 0f 6e 88 80 00 00 00 movq xmm1,QWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 66 48 0f 6e c8 movq xmm1,rax
+ +[a-f0-9]+: 66 48 0f 7e 88 80 00 00 00 movq QWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 48 0f 7e c8 movq rax,xmm1
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: c5 f9 6e c8 vmovd xmm1,eax
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: c5 f9 7e c8 vmovd eax,xmm1
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 62 f1 7d 08 6e c8 vmovd xmm1,eax
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 62 f1 7d 08 7e c8 vmovd eax,xmm1
+ +[a-f0-9]+: c4 e1 f9 6e 88 80 00 00 00 vmovq xmm1,QWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: c4 e1 f9 6e c8 vmovq xmm1,rax
+ +[a-f0-9]+: c4 e1 f9 7e 88 80 00 00 00 vmovq QWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: c4 e1 f9 7e c8 vmovq rax,xmm1
+ +[a-f0-9]+: 62 f1 fd 08 6e 48 10 vmovq xmm1,QWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 62 f1 fd 08 6e c8 vmovq xmm1,rax
+ +[a-f0-9]+: 62 f1 fd 08 7e 48 10 vmovq QWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 62 f1 fd 08 7e c8 vmovq rax,xmm1
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-movd.d b/gas/testsuite/gas/i386/x86-64-movd.d
new file mode 100644
index 0000000000..6ccd5a2ec0
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-movd.d
@@ -0,0 +1,50 @@
+#as: -J
+#objdump: -dw
+#name: x86-64 movd
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+ <_start>:
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 66 48 0f 6e c8 movq %rax,%xmm1
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 48 0f 7e c8 movq %xmm1,%rax
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: c4 e1 f9 6e c8 vmovq %rax,%xmm1
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: c4 e1 f9 7e c8 vmovq %xmm1,%rax
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 66 0f 6e c8 movd %eax,%xmm1
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 0f 7e c8 movd %xmm1,%eax
+ +[a-f0-9]+: 66 48 0f 6e 88 80 00 00 00 movq 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 66 48 0f 6e c8 movq %rax,%xmm1
+ +[a-f0-9]+: 66 48 0f 7e 88 80 00 00 00 movq %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 48 0f 7e c8 movq %xmm1,%rax
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: c5 f9 6e c8 vmovd %eax,%xmm1
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: c5 f9 7e c8 vmovd %xmm1,%eax
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 62 f1 7d 08 6e c8 vmovd %eax,%xmm1
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 62 f1 7d 08 7e c8 vmovd %xmm1,%eax
+ +[a-f0-9]+: c4 e1 f9 6e 88 80 00 00 00 vmovq 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: c4 e1 f9 6e c8 vmovq %rax,%xmm1
+ +[a-f0-9]+: c4 e1 f9 7e 88 80 00 00 00 vmovq %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: c4 e1 f9 7e c8 vmovq %xmm1,%rax
+ +[a-f0-9]+: 62 f1 fd 08 6e 48 10 vmovq 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 62 f1 fd 08 6e c8 vmovq %rax,%xmm1
+ +[a-f0-9]+: 62 f1 fd 08 7e 48 10 vmovq %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 62 f1 fd 08 7e c8 vmovq %xmm1,%rax
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-movd.s b/gas/testsuite/gas/i386/x86-64-movd.s
new file mode 100644
index 0000000000..02fced1464
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-movd.s
@@ -0,0 +1,45 @@
+# Check movd/vmovd with memory and register.
+
+ .text
+_start:
+ movd 128(%rax), %xmm1
+ movd %rax, %xmm1
+ movd %xmm1, 128(%rax)
+ movd %xmm1, %rax
+ vmovd 128(%rax), %xmm1
+ vmovd %rax, %xmm1
+ vmovd %xmm1, 128(%rax)
+ vmovd %xmm1, %rax
+ {evex} vmovd 128(%rax), %xmm1
+ {evex} vmovd %xmm1, 128(%rax)
+ .intel_syntax noprefix
+ movd xmm1, [rax + 128]
+ movd xmm1, dword ptr [rax + 128]
+ movd xmm1, eax
+ movd dword ptr [rax + 128], xmm1
+ movd [rax + 128], xmm1
+ movd eax, xmm1
+ movd xmm1, qword ptr [rax + 128]
+ movd xmm1, rax
+ movd qword ptr [rax + 128], xmm1
+ movd rax, xmm1
+ vmovd xmm1, dword ptr [rax + 128]
+ vmovd xmm1, [rax + 128]
+ vmovd xmm1, eax
+ vmovd dword ptr [rax + 128], xmm1
+ vmovd [rax + 128], xmm1
+ vmovd eax, xmm1
+ {evex} vmovd xmm1, dword ptr [rax + 128]
+ {evex} vmovd xmm1, [rax + 128]
+ {evex} vmovd xmm1, eax
+ {evex} vmovd dword ptr [rax + 128], xmm1
+ {evex} vmovd [rax + 128], xmm1
+ {evex} vmovd eax, xmm1
+ vmovd xmm1, qword ptr [rax + 128]
+ vmovd xmm1, rax
+ vmovd qword ptr [rax + 128], xmm1
+ vmovd rax, xmm1
+ {evex} vmovd xmm1, qword ptr [rax + 128]
+ {evex} vmovd xmm1, rax
+ {evex} vmovd qword ptr [rax + 128], xmm1
+ {evex} vmovd rax, xmm1
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index a9cb428226..e36e3f9e48 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2057,9 +2057,9 @@ vmovaps, 2, 0x29, None, 1, CpuAVX, Modrm|Vex|VexOpcode=0|VexW=1|CheckRegSize|No_
// support assembler for AMD64, we accept 64bit operand on vmovd so
// that we can use one template for both SSE and AVX instructions.
vmovd, 2, 0x666e, None, 1, CpuAVX, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex, RegXMM }
-vmovd, 2, 0x666e, None, 1, CpuAVX|Cpu64, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg64|Qword|BaseIndex, RegXMM }
+vmovd, 2, 0x666e, None, 1, CpuAVX|Cpu64, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Size64, { Reg64|Qword|BaseIndex, RegXMM }
vmovd, 2, 0x667e, None, 1, CpuAVX, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM, Dword|Unspecified|Reg32|BaseIndex }
-vmovd, 2, 0x667e, None, 1, CpuAVX|Cpu64, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { RegXMM, Qword|Reg64|BaseIndex }
+vmovd, 2, 0x667e, None, 1, CpuAVX|Cpu64, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Size64, { RegXMM, Reg64|Qword|BaseIndex }
vmovddup, 2, 0xf212, None, 1, CpuAVX, Modrm|Vex|VexOpcode=0|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Qword|Unspecified|BaseIndex|RegXMM, RegXMM }
vmovddup, 2, 0xf212, None, 1, CpuAVX, Modrm|Vex=2|VexOpcode=0|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Ymmword|Unspecified|BaseIndex|RegYMM, RegYMM }
vmovdqa, 2, 0x666f, None, 1, CpuAVX, Load|Modrm|Vex|VexOpcode=0|VexW=1|CheckRegSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM }
@@ -3873,9 +3873,9 @@ vmovups, 2, 0x10, None, 1, CpuAVX512F, Modrm|EVex=1|Masking=3|VexOpcode=0|VexW=1
vmovups, 2, 0x11, None, 1, CpuAVX512F, Modrm|EVex=1|Masking=3|VexOpcode=0|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegZMM, RegZMM|RegMem }
vmovd, 2, 0x666E, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex, RegXMM }
-vmovd, 2, 0x666E, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg64|Qword|Unspecified|BaseIndex, RegXMM }
+vmovd, 2, 0x666E, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg64|Qword|BaseIndex, RegXMM }
vmovd, 2, 0x667E, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM, Reg32|Dword|Unspecified|BaseIndex }
-vmovd, 2, 0x667E, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { RegXMM, Reg64|Qword|Unspecified|BaseIndex }
+vmovd, 2, 0x667E, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM, Reg64|Qword|BaseIndex }
vmovddup, 2, 0xF212, None, 1, CpuAVX512F, Modrm|EVex=1|Masking=3|VexOpcode=0|VexW=2|VecESize=1|Disp8MemShift=6|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegZMM|ZMMword|Unspecified|BaseIndex, RegZMM }
diff --git a/opcodes/i386-tbl.h b/opcodes/i386-tbl.h
index 9af048cc0c..4622b6f4e3 100644
--- a/opcodes/i386-tbl.h
+++ b/opcodes/i386-tbl.h
@@ -40861,8 +40861,8 @@ const insn_template i386_optab[] =
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 0, 0 } },
- { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
+ { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 1,
+ 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0 },
{ { { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
@@ -40895,8 +40895,8 @@ const insn_template i386_optab[] =
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 0, 0 } },
- { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
+ { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 1,
+ 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0 },
{ { { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -40930,11 +40930,11 @@ const insn_template i386_optab[] =
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 0, 0 } },
{ 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
- 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 2, 0, 0, 0,
+ 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 4, 0, 1, 0, 0, 0, 3, 0, 0, 0,
0, 0, 0, 0, 0 },
{ { { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0,
+ 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0,
0, 0, 0 } },
{ { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0,
@@ -40964,14 +40964,14 @@ const insn_template i386_optab[] =
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 0, 0 } },
{ 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
- 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 2, 0, 0, 0,
+ 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 4, 0, 1, 0, 0, 0, 3, 0, 0, 0,
0, 0, 0, 0, 0 },
{ { { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0,
0, 0, 0 } },
{ { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0,
+ 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0,
0, 0, 0 } } } },
{ "vmovddup", 2, 0xf212, None, 1,
{ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
--
2.14.3
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 1:18 [PATCH] x86: Properly encode vmovd with 64-bit memeory H.J. Lu
@ 2018-01-08 8:48 ` Jan Beulich
2018-01-08 11:14 ` H.J. Lu
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2018-01-08 8:48 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
>>> On 08.01.18 at 02:18, <hongjiu.lu@intel.com> wrote:
> For historical reason, we allow movd/vmovd with 64-bit register and
> memeory operands. But for vmovd, we failed to handle 64-bit memeory
> operand. This has been gone unnoticed since AT&T syntax always treats
> memory operand as 32-bit memory. This patch properly encodes vmovd
> with 64-bit memeory operands.
Interesting coincidence - just over the weekend I've run into this
issue too. My intended solution is quite different, though: Since
VMOVD (other than MOVD) doesn't have a 64-bit operand variant
in either Intel's SDM nor AMD's PM, I'd rather remove memory
operand support from it:
- generate code was wrong so far, so anyone having used it would
have run buggy code anyway,
- old gcc only ever uses the 64-bit variants with register operands.
Furthermore I think that the AVX512 64-bit variant should go away
altogether - it's register form is just a longer re-encoding of the
AVX form, and hence redundant, and gcc (afaics) doesn't use it.
One other oddity I've noticed in this context is the difference in
encoding choice between AVX and AVX512 VMOVQ with memory
operand: While the former uses the forms allowing for an XMM
register as alternative to the memory operand, the latter uses
the forms alternatively allowing for a GPR in 64-bit mode, and
the other one only in 32-bit mode. There's no comment there, so
I wonder whether this is intentional or an unnecessary
divergence.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 8:48 ` Jan Beulich
@ 2018-01-08 11:14 ` H.J. Lu
2018-01-08 11:22 ` H.J. Lu
2018-01-08 11:39 ` Jan Beulich
0 siblings, 2 replies; 16+ messages in thread
From: H.J. Lu @ 2018-01-08 11:14 UTC (permalink / raw)
To: Jan Beulich; +Cc: Binutils
On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 08.01.18 at 02:18, <hongjiu.lu@intel.com> wrote:
>> For historical reason, we allow movd/vmovd with 64-bit register and
>> memeory operands. But for vmovd, we failed to handle 64-bit memeory
>> operand. This has been gone unnoticed since AT&T syntax always treats
>> memory operand as 32-bit memory. This patch properly encodes vmovd
>> with 64-bit memeory operands.
>
> Interesting coincidence - just over the weekend I've run into this
> issue too. My intended solution is quite different, though: Since
> VMOVD (other than MOVD) doesn't have a 64-bit operand variant
> in either Intel's SDM nor AMD's PM, I'd rather remove memory
> operand support from it:
> - generate code was wrong so far, so anyone having used it would
> have run buggy code anyway,
> - old gcc only ever uses the 64-bit variants with register operands.
Works for me. Can you submit a patch?
> Furthermore I think that the AVX512 64-bit variant should go away
> altogether - it's register form is just a longer re-encoding of the
> AVX form, and hence redundant, and gcc (afaics) doesn't use it.
Shouln't vmovd with upper 32 xmm registers be encoded with AVX512?
> One other oddity I've noticed in this context is the difference in
> encoding choice between AVX and AVX512 VMOVQ with memory
> operand: While the former uses the forms allowing for an XMM
> register as alternative to the memory operand, the latter uses
> the forms alternatively allowing for a GPR in 64-bit mode, and
> the other one only in 32-bit mode. There's no comment there, so
> I wonder whether this is intentional or an unnecessary
> divergence.
I prefer to leave it alone.
Thanks.
--
H.J.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 11:14 ` H.J. Lu
@ 2018-01-08 11:22 ` H.J. Lu
2018-01-08 11:36 ` Jan Beulich
2018-01-08 11:39 ` Jan Beulich
1 sibling, 1 reply; 16+ messages in thread
From: H.J. Lu @ 2018-01-08 11:22 UTC (permalink / raw)
To: Jan Beulich; +Cc: Binutils
On Mon, Jan 8, 2018 at 3:14 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 08.01.18 at 02:18, <hongjiu.lu@intel.com> wrote:
>>> For historical reason, we allow movd/vmovd with 64-bit register and
>>> memeory operands. But for vmovd, we failed to handle 64-bit memeory
>>> operand. This has been gone unnoticed since AT&T syntax always treats
>>> memory operand as 32-bit memory. This patch properly encodes vmovd
>>> with 64-bit memeory operands.
>>
>> Interesting coincidence - just over the weekend I've run into this
>> issue too. My intended solution is quite different, though: Since
>> VMOVD (other than MOVD) doesn't have a 64-bit operand variant
>> in either Intel's SDM nor AMD's PM, I'd rather remove memory
>> operand support from it:
>> - generate code was wrong so far, so anyone having used it would
>> have run buggy code anyway,
>> - old gcc only ever uses the 64-bit variants with register operands.
>
> Works for me. Can you submit a patch?
If we do that, should we also remove MOVD with 64-bit memory?
Otherwise, -msse2avx won't work on MOVD with 64-bit memory.
>> Furthermore I think that the AVX512 64-bit variant should go away
>> altogether - it's register form is just a longer re-encoding of the
>> AVX form, and hence redundant, and gcc (afaics) doesn't use it.
>
> Shouln't vmovd with upper 32 xmm registers be encoded with AVX512?
>
>> One other oddity I've noticed in this context is the difference in
>> encoding choice between AVX and AVX512 VMOVQ with memory
>> operand: While the former uses the forms allowing for an XMM
>> register as alternative to the memory operand, the latter uses
>> the forms alternatively allowing for a GPR in 64-bit mode, and
>> the other one only in 32-bit mode. There's no comment there, so
>> I wonder whether this is intentional or an unnecessary
>> divergence.
>
> I prefer to leave it alone.
>
> Thanks.
>
> --
> H.J.
--
H.J.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 11:22 ` H.J. Lu
@ 2018-01-08 11:36 ` Jan Beulich
2018-01-08 11:49 ` H.J. Lu
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2018-01-08 11:36 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils
>>> On 08.01.18 at 12:22, <hjl.tools@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 3:14 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 08.01.18 at 02:18, <hongjiu.lu@intel.com> wrote:
>>>> For historical reason, we allow movd/vmovd with 64-bit register and
>>>> memeory operands. But for vmovd, we failed to handle 64-bit memeory
>>>> operand. This has been gone unnoticed since AT&T syntax always treats
>>>> memory operand as 32-bit memory. This patch properly encodes vmovd
>>>> with 64-bit memeory operands.
>>>
>>> Interesting coincidence - just over the weekend I've run into this
>>> issue too. My intended solution is quite different, though: Since
>>> VMOVD (other than MOVD) doesn't have a 64-bit operand variant
>>> in either Intel's SDM nor AMD's PM, I'd rather remove memory
>>> operand support from it:
>>> - generate code was wrong so far, so anyone having used it would
>>> have run buggy code anyway,
>>> - old gcc only ever uses the 64-bit variants with register operands.
>>
>> Works for me. Can you submit a patch?
Hopefully later this week.
> If we do that, should we also remove MOVD with 64-bit memory?
We can't, as even up-to-date AMD PM still specifies this name
instead of MOVQ.
> Otherwise, -msse2avx won't work on MOVD with 64-bit memory.
Hmm, good point - perhaps the SSE2AVX pattern then needs the
change that you've been doing, while the plain one could have its
memory alternative removed?
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 11:14 ` H.J. Lu
2018-01-08 11:22 ` H.J. Lu
@ 2018-01-08 11:39 ` Jan Beulich
2018-01-08 11:52 ` H.J. Lu
1 sibling, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2018-01-08 11:39 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils
>>> On 08.01.18 at 12:14, <hjl.tools@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Furthermore I think that the AVX512 64-bit variant should go away
>> altogether - it's register form is just a longer re-encoding of the
>> AVX form, and hence redundant, and gcc (afaics) doesn't use it.
>
> Shouln't vmovd with upper 32 xmm registers be encoded with AVX512?
No, such an instruction simply doesn't exist (as per SDM). The
difference to the AVX flavor is that gcc new enough to support
AVX512 is also new enough to check for the availability of the
well-formed VMOVQ, and there's also no mode equivalent to
SSE2AVX to take care of.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 11:36 ` Jan Beulich
@ 2018-01-08 11:49 ` H.J. Lu
2018-01-08 11:54 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: H.J. Lu @ 2018-01-08 11:49 UTC (permalink / raw)
To: Jan Beulich; +Cc: Binutils
On Mon, Jan 8, 2018 at 3:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 08.01.18 at 12:22, <hjl.tools@gmail.com> wrote:
>> On Mon, Jan 8, 2018 at 3:14 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 08.01.18 at 02:18, <hongjiu.lu@intel.com> wrote:
>>>>> For historical reason, we allow movd/vmovd with 64-bit register and
>>>>> memeory operands. But for vmovd, we failed to handle 64-bit memeory
>>>>> operand. This has been gone unnoticed since AT&T syntax always treats
>>>>> memory operand as 32-bit memory. This patch properly encodes vmovd
>>>>> with 64-bit memeory operands.
>>>>
>>>> Interesting coincidence - just over the weekend I've run into this
>>>> issue too. My intended solution is quite different, though: Since
>>>> VMOVD (other than MOVD) doesn't have a 64-bit operand variant
>>>> in either Intel's SDM nor AMD's PM, I'd rather remove memory
>>>> operand support from it:
>>>> - generate code was wrong so far, so anyone having used it would
>>>> have run buggy code anyway,
>>>> - old gcc only ever uses the 64-bit variants with register operands.
>>>
>>> Works for me. Can you submit a patch?
>
> Hopefully later this week.
>
>> If we do that, should we also remove MOVD with 64-bit memory?
>
> We can't, as even up-to-date AMD PM still specifies this name
> instead of MOVQ.
I consider it is a defect in AMD manual.
>> Otherwise, -msse2avx won't work on MOVD with 64-bit memory.
>
> Hmm, good point - perhaps the SSE2AVX pattern then needs the
> change that you've been doing, while the plain one could have its
> memory alternative removed?
If we can't remove MOVD with 64-bit memory, I will go with my patch.
--
H.J.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 11:39 ` Jan Beulich
@ 2018-01-08 11:52 ` H.J. Lu
2018-01-08 12:13 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: H.J. Lu @ 2018-01-08 11:52 UTC (permalink / raw)
To: Jan Beulich; +Cc: Binutils
On Mon, Jan 8, 2018 at 3:39 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 08.01.18 at 12:14, <hjl.tools@gmail.com> wrote:
>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> Furthermore I think that the AVX512 64-bit variant should go away
>>> altogether - it's register form is just a longer re-encoding of the
>>> AVX form, and hence redundant, and gcc (afaics) doesn't use it.
>>
>> Shouln't vmovd with upper 32 xmm registers be encoded with AVX512?
>
> No, such an instruction simply doesn't exist (as per SDM). The
What do you mean by that? These
vmovd 128(%rax), %xmm19
vmovd %rax, %xmm19
vmovd %xmm19, 128(%rax)
vmovd %xmm19, %rax
.intel_syntax noprefix
vmovd xmm19, qword ptr [rax + 128]
vmovd xmm19, rax
vmovd qword ptr [rax + 128], xmm19
vmovd rax, xmm19
are encoded with AVX512.
> difference to the AVX flavor is that gcc new enough to support
> AVX512 is also new enough to check for the availability of the
> well-formed VMOVQ, and there's also no mode equivalent to
> SSE2AVX to take care of.
GCC has
case TYPE_SSEMOV:
switch (get_attr_mode (insn))
{
case MODE_DI:
/* Handle broken assemblers that require movd instead of movq. */
if (!HAVE_AS_IX86_INTERUNIT_MOVQ
&& (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
return "%vmovd\t{%1, %0|%0, %1}";
return "%vmovq\t{%1, %0|%0, %1}";
It doesn't check upper 32 xmm registers.
--
H.J.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 11:49 ` H.J. Lu
@ 2018-01-08 11:54 ` Jan Beulich
2018-01-08 11:57 ` H.J. Lu
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2018-01-08 11:54 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils
>>> On 08.01.18 at 12:48, <hjl.tools@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 3:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 08.01.18 at 12:22, <hjl.tools@gmail.com> wrote:
>>> On Mon, Jan 8, 2018 at 3:14 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 08.01.18 at 02:18, <hongjiu.lu@intel.com> wrote:
>>>>>> For historical reason, we allow movd/vmovd with 64-bit register and
>>>>>> memeory operands. But for vmovd, we failed to handle 64-bit memeory
>>>>>> operand. This has been gone unnoticed since AT&T syntax always treats
>>>>>> memory operand as 32-bit memory. This patch properly encodes vmovd
>>>>>> with 64-bit memeory operands.
>>>>>
>>>>> Interesting coincidence - just over the weekend I've run into this
>>>>> issue too. My intended solution is quite different, though: Since
>>>>> VMOVD (other than MOVD) doesn't have a 64-bit operand variant
>>>>> in either Intel's SDM nor AMD's PM, I'd rather remove memory
>>>>> operand support from it:
>>>>> - generate code was wrong so far, so anyone having used it would
>>>>> have run buggy code anyway,
>>>>> - old gcc only ever uses the 64-bit variants with register operands.
>>>>
>>>> Works for me. Can you submit a patch?
>>
>> Hopefully later this week.
>>
>>> If we do that, should we also remove MOVD with 64-bit memory?
>>
>> We can't, as even up-to-date AMD PM still specifies this name
>> instead of MOVQ.
>
> I consider it is a defect in AMD manual.
>
>>> Otherwise, -msse2avx won't work on MOVD with 64-bit memory.
>>
>> Hmm, good point - perhaps the SSE2AVX pattern then needs the
>> change that you've been doing, while the plain one could have its
>> memory alternative removed?
>
> If we can't remove MOVD with 64-bit memory, I will go with my patch.
Fine with me for the AVX variant, but please consider dropping
the AVX512 one.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 11:54 ` Jan Beulich
@ 2018-01-08 11:57 ` H.J. Lu
2018-01-08 12:08 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: H.J. Lu @ 2018-01-08 11:57 UTC (permalink / raw)
To: Jan Beulich; +Cc: Binutils
On Mon, Jan 8, 2018 at 3:54 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 08.01.18 at 12:48, <hjl.tools@gmail.com> wrote:
>> On Mon, Jan 8, 2018 at 3:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 08.01.18 at 12:22, <hjl.tools@gmail.com> wrote:
>>>> On Mon, Jan 8, 2018 at 3:14 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>>> On 08.01.18 at 02:18, <hongjiu.lu@intel.com> wrote:
>>>>>>> For historical reason, we allow movd/vmovd with 64-bit register and
>>>>>>> memeory operands. But for vmovd, we failed to handle 64-bit memeory
>>>>>>> operand. This has been gone unnoticed since AT&T syntax always treats
>>>>>>> memory operand as 32-bit memory. This patch properly encodes vmovd
>>>>>>> with 64-bit memeory operands.
>>>>>>
>>>>>> Interesting coincidence - just over the weekend I've run into this
>>>>>> issue too. My intended solution is quite different, though: Since
>>>>>> VMOVD (other than MOVD) doesn't have a 64-bit operand variant
>>>>>> in either Intel's SDM nor AMD's PM, I'd rather remove memory
>>>>>> operand support from it:
>>>>>> - generate code was wrong so far, so anyone having used it would
>>>>>> have run buggy code anyway,
>>>>>> - old gcc only ever uses the 64-bit variants with register operands.
>>>>>
>>>>> Works for me. Can you submit a patch?
>>>
>>> Hopefully later this week.
>>>
>>>> If we do that, should we also remove MOVD with 64-bit memory?
>>>
>>> We can't, as even up-to-date AMD PM still specifies this name
>>> instead of MOVQ.
>>
>> I consider it is a defect in AMD manual.
>>
>>>> Otherwise, -msse2avx won't work on MOVD with 64-bit memory.
>>>
>>> Hmm, good point - perhaps the SSE2AVX pattern then needs the
>>> change that you've been doing, while the plain one could have its
>>> memory alternative removed?
>>
>> If we can't remove MOVD with 64-bit memory, I will go with my patch.
>
> Fine with me for the AVX variant, but please consider dropping
> the AVX512 one.
Did you mean dropping AVX512 vmovd with 64-bit memory operand?
--
H.J.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 11:57 ` H.J. Lu
@ 2018-01-08 12:08 ` Jan Beulich
0 siblings, 0 replies; 16+ messages in thread
From: Jan Beulich @ 2018-01-08 12:08 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils
>>> On 08.01.18 at 12:57, <hjl.tools@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 3:54 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 08.01.18 at 12:48, <hjl.tools@gmail.com> wrote:
>>> On Mon, Jan 8, 2018 at 3:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 08.01.18 at 12:22, <hjl.tools@gmail.com> wrote:
>>>>> On Mon, Jan 8, 2018 at 3:14 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>>>> On 08.01.18 at 02:18, <hongjiu.lu@intel.com> wrote:
>>>>>>>> For historical reason, we allow movd/vmovd with 64-bit register and
>>>>>>>> memeory operands. But for vmovd, we failed to handle 64-bit memeory
>>>>>>>> operand. This has been gone unnoticed since AT&T syntax always treats
>>>>>>>> memory operand as 32-bit memory. This patch properly encodes vmovd
>>>>>>>> with 64-bit memeory operands.
>>>>>>>
>>>>>>> Interesting coincidence - just over the weekend I've run into this
>>>>>>> issue too. My intended solution is quite different, though: Since
>>>>>>> VMOVD (other than MOVD) doesn't have a 64-bit operand variant
>>>>>>> in either Intel's SDM nor AMD's PM, I'd rather remove memory
>>>>>>> operand support from it:
>>>>>>> - generate code was wrong so far, so anyone having used it would
>>>>>>> have run buggy code anyway,
>>>>>>> - old gcc only ever uses the 64-bit variants with register operands.
>>>>>>
>>>>>> Works for me. Can you submit a patch?
>>>>
>>>> Hopefully later this week.
>>>>
>>>>> If we do that, should we also remove MOVD with 64-bit memory?
>>>>
>>>> We can't, as even up-to-date AMD PM still specifies this name
>>>> instead of MOVQ.
>>>
>>> I consider it is a defect in AMD manual.
>>>
>>>>> Otherwise, -msse2avx won't work on MOVD with 64-bit memory.
>>>>
>>>> Hmm, good point - perhaps the SSE2AVX pattern then needs the
>>>> change that you've been doing, while the plain one could have its
>>>> memory alternative removed?
>>>
>>> If we can't remove MOVD with 64-bit memory, I will go with my patch.
>>
>> Fine with me for the AVX variant, but please consider dropping
>> the AVX512 one.
>
> Did you mean dropping AVX512 vmovd with 64-bit memory operand?
Considering your other reply - yes, at least please drop the
memory operand from it.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 11:52 ` H.J. Lu
@ 2018-01-08 12:13 ` Jan Beulich
2018-01-08 12:17 ` H.J. Lu
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2018-01-08 12:13 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils
>>> On 08.01.18 at 12:52, <hjl.tools@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 3:39 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 08.01.18 at 12:14, <hjl.tools@gmail.com> wrote:
>>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> Furthermore I think that the AVX512 64-bit variant should go away
>>>> altogether - it's register form is just a longer re-encoding of the
>>>> AVX form, and hence redundant, and gcc (afaics) doesn't use it.
>>>
>>> Shouln't vmovd with upper 32 xmm registers be encoded with AVX512?
>>
>> No, such an instruction simply doesn't exist (as per SDM). The
>
> What do you mean by that? These
>
> vmovd 128(%rax), %xmm19
As per the SDM this one is a 32-bit operation.
> vmovd %rax, %xmm19
As per the SDM this one doesn't exist.
> vmovd %xmm19, 128(%rax)
32-bit again.
> vmovd %xmm19, %rax
non-existing again.
> .intel_syntax noprefix
> vmovd xmm19, qword ptr [rax + 128]
> vmovd xmm19, rax
> vmovd qword ptr [rax + 128], xmm19
> vmovd rax, xmm19
>
> are encoded with AVX512.
>
>> difference to the AVX flavor is that gcc new enough to support
>> AVX512 is also new enough to check for the availability of the
>> well-formed VMOVQ, and there's also no mode equivalent to
>> SSE2AVX to take care of.
>
> GCC has
>
> case TYPE_SSEMOV:
> switch (get_attr_mode (insn))
> {
> case MODE_DI:
> /* Handle broken assemblers that require movd instead of movq. */
> if (!HAVE_AS_IX86_INTERUNIT_MOVQ
> && (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
> return "%vmovd\t{%1, %0|%0, %1}";
> return "%vmovq\t{%1, %0|%0, %1}";
>
> It doesn't check upper 32 xmm registers.
Ah, yes you're right. See also my other reply just sent.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 12:13 ` Jan Beulich
@ 2018-01-08 12:17 ` H.J. Lu
2018-01-08 12:34 ` H.J. Lu
0 siblings, 1 reply; 16+ messages in thread
From: H.J. Lu @ 2018-01-08 12:17 UTC (permalink / raw)
To: Jan Beulich; +Cc: Binutils
On Mon, Jan 8, 2018 at 4:12 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 08.01.18 at 12:52, <hjl.tools@gmail.com> wrote:
>> On Mon, Jan 8, 2018 at 3:39 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 08.01.18 at 12:14, <hjl.tools@gmail.com> wrote:
>>>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> Furthermore I think that the AVX512 64-bit variant should go away
>>>>> altogether - it's register form is just a longer re-encoding of the
>>>>> AVX form, and hence redundant, and gcc (afaics) doesn't use it.
>>>>
>>>> Shouln't vmovd with upper 32 xmm registers be encoded with AVX512?
>>>
>>> No, such an instruction simply doesn't exist (as per SDM). The
>>
>> What do you mean by that? These
>>
>> vmovd 128(%rax), %xmm19
>
> As per the SDM this one is a 32-bit operation.
>
>> vmovd %rax, %xmm19
>
> As per the SDM this one doesn't exist.
>
>> vmovd %xmm19, 128(%rax)
>
> 32-bit again.
>
>> vmovd %xmm19, %rax
>
> non-existing again.
>
>> .intel_syntax noprefix
>> vmovd xmm19, qword ptr [rax + 128]
>> vmovd xmm19, rax
>> vmovd qword ptr [rax + 128], xmm19
>> vmovd rax, xmm19
>>
>> are encoded with AVX512.
>>
>>> difference to the AVX flavor is that gcc new enough to support
>>> AVX512 is also new enough to check for the availability of the
>>> well-formed VMOVQ, and there's also no mode equivalent to
>>> SSE2AVX to take care of.
>>
>> GCC has
>>
>> case TYPE_SSEMOV:
>> switch (get_attr_mode (insn))
>> {
>> case MODE_DI:
>> /* Handle broken assemblers that require movd instead of movq. */
>> if (!HAVE_AS_IX86_INTERUNIT_MOVQ
>> && (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
>> return "%vmovd\t{%1, %0|%0, %1}";
>> return "%vmovq\t{%1, %0|%0, %1}";
>>
>> It doesn't check upper 32 xmm registers.
>
> Ah, yes you're right. See also my other reply just sent.
I just realized that all AVX512 assemblers set HAVE_AS_IX86_INTERUNIT_MOVQ.
We can remove AVX512 vmovd after all.
--
H.J.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 12:17 ` H.J. Lu
@ 2018-01-08 12:34 ` H.J. Lu
2018-01-08 12:56 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: H.J. Lu @ 2018-01-08 12:34 UTC (permalink / raw)
To: Jan Beulich; +Cc: Binutils
[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]
On Mon, Jan 8, 2018 at 4:17 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 4:12 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 08.01.18 at 12:52, <hjl.tools@gmail.com> wrote:
>>> On Mon, Jan 8, 2018 at 3:39 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 08.01.18 at 12:14, <hjl.tools@gmail.com> wrote:
>>>>> On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> Furthermore I think that the AVX512 64-bit variant should go away
>>>>>> altogether - it's register form is just a longer re-encoding of the
>>>>>> AVX form, and hence redundant, and gcc (afaics) doesn't use it.
>>>>>
>>>>> Shouln't vmovd with upper 32 xmm registers be encoded with AVX512?
>>>>
>>>> No, such an instruction simply doesn't exist (as per SDM). The
>>>
>>> What do you mean by that? These
>>>
>>> vmovd 128(%rax), %xmm19
>>
>> As per the SDM this one is a 32-bit operation.
>>
>>> vmovd %rax, %xmm19
>>
>> As per the SDM this one doesn't exist.
>>
>>> vmovd %xmm19, 128(%rax)
>>
>> 32-bit again.
>>
>>> vmovd %xmm19, %rax
>>
>> non-existing again.
>>
>>> .intel_syntax noprefix
>>> vmovd xmm19, qword ptr [rax + 128]
>>> vmovd xmm19, rax
>>> vmovd qword ptr [rax + 128], xmm19
>>> vmovd rax, xmm19
>>>
>>> are encoded with AVX512.
>>>
>>>> difference to the AVX flavor is that gcc new enough to support
>>>> AVX512 is also new enough to check for the availability of the
>>>> well-formed VMOVQ, and there's also no mode equivalent to
>>>> SSE2AVX to take care of.
>>>
>>> GCC has
>>>
>>> case TYPE_SSEMOV:
>>> switch (get_attr_mode (insn))
>>> {
>>> case MODE_DI:
>>> /* Handle broken assemblers that require movd instead of movq. */
>>> if (!HAVE_AS_IX86_INTERUNIT_MOVQ
>>> && (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
>>> return "%vmovd\t{%1, %0|%0, %1}";
>>> return "%vmovq\t{%1, %0|%0, %1}";
>>>
>>> It doesn't check upper 32 xmm registers.
>>
>> Ah, yes you're right. See also my other reply just sent.
>
> I just realized that all AVX512 assemblers set HAVE_AS_IX86_INTERUNIT_MOVQ.
> We can remove AVX512 vmovd after all.
>
This is what I am checking in.
--
H.J.
[-- Attachment #2: 0001-x86-Properly-encode-vmovd-with-64-bit-memeory.patch --]
[-- Type: application/octet-stream, Size: 16905 bytes --]
From 614da360a01b215e877fcda123675e0f1a1c5f5d Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Sun, 7 Jan 2018 16:57:04 -0800
Subject: [PATCH] x86: Properly encode vmovd with 64-bit memeory
For historical reason, we allow movd/vmovd with 64-bit register and
memeory operands. But for vmovd, we failed to handle 64-bit memeory
operand. This has been gone unnoticed since AT&T syntax always treats
memory operand as 32-bit memory. This patch properly encodes vmovd
with 64-bit memeory operands. It also removes AVX512 vmovd with 64-bit
operands since GCC has
case TYPE_SSEMOV:
switch (get_attr_mode (insn))
{
case MODE_DI:
/* Handle broken assemblers that require movd instead of movq. */
if (!HAVE_AS_IX86_INTERUNIT_MOVQ
&& (GENERAL_REG_P (operands[0]) || GENERAL_REG_P (operands[1])))
return "%vmovd\t{%1, %0|%0, %1}";
return "%vmovq\t{%1, %0|%0, %1}";
and all AVX512 GNU assemblers set HAVE_AS_IX86_INTERUNIT_MOVQ, GCC won't
generate AVX512 vmovd with 64-bit operand.
gas/
PR gas/22681
* testsuite/gas/i386/i386.exp: Run x86-64-movd and
x86-64-movd-intel.
* testsuite/gas/i386/x86-64-movd-intel.d: New file.
* testsuite/gas/i386/x86-64-movd.d: Likewise.
* testsuite/gas/i386/x86-64-movd.s: Likewise.
opcodes/
PR gas/22681
* i386-opc.tbl: Properly encode vmovd with Qword memeory operand.
Remove AVX512 vmovd with 64-bit operands.
* i386-tbl.h: Regenerated.
---
gas/testsuite/gas/i386/i386.exp | 2 ++
gas/testsuite/gas/i386/x86-64-movd-intel.d | 47 ++++++++++++++++++++++++++++++
gas/testsuite/gas/i386/x86-64-movd.d | 46 +++++++++++++++++++++++++++++
gas/testsuite/gas/i386/x86-64-movd.s | 41 ++++++++++++++++++++++++++
opcodes/i386-opc.tbl | 6 ++--
opcodes/i386-tbl.h | 42 +++-----------------------
6 files changed, 142 insertions(+), 42 deletions(-)
create mode 100644 gas/testsuite/gas/i386/x86-64-movd-intel.d
create mode 100644 gas/testsuite/gas/i386/x86-64-movd.d
create mode 100644 gas/testsuite/gas/i386/x86-64-movd.s
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 3fd0e4633d..20bcf91823 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -900,6 +900,8 @@ if [expr ([istarget "i*86-*-*"] || [istarget "x86_64-*-*"]) && [gas_64_check]] t
run_dump_test "x86-64-notrack"
run_dump_test "x86-64-notrack-intel"
run_list_test "x86-64-notrackbad" "-al"
+ run_dump_test "x86-64-movd"
+ run_dump_test "x86-64-movd-intel"
if { ![istarget "*-*-aix*"]
&& ![istarget "*-*-beos*"]
diff --git a/gas/testsuite/gas/i386/x86-64-movd-intel.d b/gas/testsuite/gas/i386/x86-64-movd-intel.d
new file mode 100644
index 0000000000..fe99f626fe
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-movd-intel.d
@@ -0,0 +1,47 @@
+#source: x86-64-movd.s
+#as: -J
+#objdump: -dw -Mintel
+#name: x86-64 movd (Intel mode)
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+ <_start>:
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 66 48 0f 6e c8 movq xmm1,rax
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 48 0f 7e c8 movq rax,xmm1
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: c4 e1 f9 6e c8 vmovq xmm1,rax
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: c4 e1 f9 7e c8 vmovq rax,xmm1
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 66 0f 6e c8 movd xmm1,eax
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 0f 7e c8 movd eax,xmm1
+ +[a-f0-9]+: 66 48 0f 6e 88 80 00 00 00 movq xmm1,QWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 66 48 0f 6e c8 movq xmm1,rax
+ +[a-f0-9]+: 66 48 0f 7e 88 80 00 00 00 movq QWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 66 48 0f 7e c8 movq rax,xmm1
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: c5 f9 6e c8 vmovd xmm1,eax
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: c5 f9 7e c8 vmovd eax,xmm1
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd xmm1,DWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: 62 f1 7d 08 6e c8 vmovd xmm1,eax
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd DWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: 62 f1 7d 08 7e c8 vmovd eax,xmm1
+ +[a-f0-9]+: c4 e1 f9 6e 88 80 00 00 00 vmovq xmm1,QWORD PTR \[rax\+0x80\]
+ +[a-f0-9]+: c4 e1 f9 6e c8 vmovq xmm1,rax
+ +[a-f0-9]+: c4 e1 f9 7e 88 80 00 00 00 vmovq QWORD PTR \[rax\+0x80\],xmm1
+ +[a-f0-9]+: c4 e1 f9 7e c8 vmovq rax,xmm1
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-movd.d b/gas/testsuite/gas/i386/x86-64-movd.d
new file mode 100644
index 0000000000..5d4a6c61e8
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-movd.d
@@ -0,0 +1,46 @@
+#as: -J
+#objdump: -dw
+#name: x86-64 movd
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+ <_start>:
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 66 48 0f 6e c8 movq %rax,%xmm1
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 48 0f 7e c8 movq %xmm1,%rax
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: c4 e1 f9 6e c8 vmovq %rax,%xmm1
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: c4 e1 f9 7e c8 vmovq %xmm1,%rax
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 66 0f 6e 88 80 00 00 00 movd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 66 0f 6e c8 movd %eax,%xmm1
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 0f 7e 88 80 00 00 00 movd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 0f 7e c8 movd %xmm1,%eax
+ +[a-f0-9]+: 66 48 0f 6e 88 80 00 00 00 movq 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 66 48 0f 6e c8 movq %rax,%xmm1
+ +[a-f0-9]+: 66 48 0f 7e 88 80 00 00 00 movq %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 66 48 0f 7e c8 movq %xmm1,%rax
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: c5 f9 6e 88 80 00 00 00 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: c5 f9 6e c8 vmovd %eax,%xmm1
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: c5 f9 7e 88 80 00 00 00 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: c5 f9 7e c8 vmovd %xmm1,%eax
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 62 f1 7d 08 6e 48 20 vmovd 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: 62 f1 7d 08 6e c8 vmovd %eax,%xmm1
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 62 f1 7d 08 7e 48 20 vmovd %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: 62 f1 7d 08 7e c8 vmovd %xmm1,%eax
+ +[a-f0-9]+: c4 e1 f9 6e 88 80 00 00 00 vmovq 0x80\(%rax\),%xmm1
+ +[a-f0-9]+: c4 e1 f9 6e c8 vmovq %rax,%xmm1
+ +[a-f0-9]+: c4 e1 f9 7e 88 80 00 00 00 vmovq %xmm1,0x80\(%rax\)
+ +[a-f0-9]+: c4 e1 f9 7e c8 vmovq %xmm1,%rax
+#pass
diff --git a/gas/testsuite/gas/i386/x86-64-movd.s b/gas/testsuite/gas/i386/x86-64-movd.s
new file mode 100644
index 0000000000..1722cef2a3
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-movd.s
@@ -0,0 +1,41 @@
+# Check movd/vmovd with memory and register.
+
+ .text
+_start:
+ movd 128(%rax), %xmm1
+ movd %rax, %xmm1
+ movd %xmm1, 128(%rax)
+ movd %xmm1, %rax
+ vmovd 128(%rax), %xmm1
+ vmovd %rax, %xmm1
+ vmovd %xmm1, 128(%rax)
+ vmovd %xmm1, %rax
+ {evex} vmovd 128(%rax), %xmm1
+ {evex} vmovd %xmm1, 128(%rax)
+ .intel_syntax noprefix
+ movd xmm1, [rax + 128]
+ movd xmm1, dword ptr [rax + 128]
+ movd xmm1, eax
+ movd dword ptr [rax + 128], xmm1
+ movd [rax + 128], xmm1
+ movd eax, xmm1
+ movd xmm1, qword ptr [rax + 128]
+ movd xmm1, rax
+ movd qword ptr [rax + 128], xmm1
+ movd rax, xmm1
+ vmovd xmm1, dword ptr [rax + 128]
+ vmovd xmm1, [rax + 128]
+ vmovd xmm1, eax
+ vmovd dword ptr [rax + 128], xmm1
+ vmovd [rax + 128], xmm1
+ vmovd eax, xmm1
+ {evex} vmovd xmm1, dword ptr [rax + 128]
+ {evex} vmovd xmm1, [rax + 128]
+ {evex} vmovd xmm1, eax
+ {evex} vmovd dword ptr [rax + 128], xmm1
+ {evex} vmovd [rax + 128], xmm1
+ {evex} vmovd eax, xmm1
+ vmovd xmm1, qword ptr [rax + 128]
+ vmovd xmm1, rax
+ vmovd qword ptr [rax + 128], xmm1
+ vmovd rax, xmm1
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index a9cb428226..464add0804 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2057,9 +2057,9 @@ vmovaps, 2, 0x29, None, 1, CpuAVX, Modrm|Vex|VexOpcode=0|VexW=1|CheckRegSize|No_
// support assembler for AMD64, we accept 64bit operand on vmovd so
// that we can use one template for both SSE and AVX instructions.
vmovd, 2, 0x666e, None, 1, CpuAVX, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex, RegXMM }
-vmovd, 2, 0x666e, None, 1, CpuAVX|Cpu64, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg64|Qword|BaseIndex, RegXMM }
+vmovd, 2, 0x666e, None, 1, CpuAVX|Cpu64, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Size64, { Reg64|Qword|BaseIndex, RegXMM }
vmovd, 2, 0x667e, None, 1, CpuAVX, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM, Dword|Unspecified|Reg32|BaseIndex }
-vmovd, 2, 0x667e, None, 1, CpuAVX|Cpu64, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { RegXMM, Qword|Reg64|BaseIndex }
+vmovd, 2, 0x667e, None, 1, CpuAVX|Cpu64, Modrm|Vex=3|VexOpcode=0|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Size64, { RegXMM, Reg64|Qword|BaseIndex }
vmovddup, 2, 0xf212, None, 1, CpuAVX, Modrm|Vex|VexOpcode=0|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Qword|Unspecified|BaseIndex|RegXMM, RegXMM }
vmovddup, 2, 0xf212, None, 1, CpuAVX, Modrm|Vex=2|VexOpcode=0|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Ymmword|Unspecified|BaseIndex|RegYMM, RegYMM }
vmovdqa, 2, 0x666f, None, 1, CpuAVX, Load|Modrm|Vex|VexOpcode=0|VexW=1|CheckRegSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM }
@@ -3873,9 +3873,7 @@ vmovups, 2, 0x10, None, 1, CpuAVX512F, Modrm|EVex=1|Masking=3|VexOpcode=0|VexW=1
vmovups, 2, 0x11, None, 1, CpuAVX512F, Modrm|EVex=1|Masking=3|VexOpcode=0|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegZMM, RegZMM|RegMem }
vmovd, 2, 0x666E, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex, RegXMM }
-vmovd, 2, 0x666E, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg64|Qword|Unspecified|BaseIndex, RegXMM }
vmovd, 2, 0x667E, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM, Reg32|Dword|Unspecified|BaseIndex }
-vmovd, 2, 0x667E, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { RegXMM, Reg64|Qword|Unspecified|BaseIndex }
vmovddup, 2, 0xF212, None, 1, CpuAVX512F, Modrm|EVex=1|Masking=3|VexOpcode=0|VexW=2|VecESize=1|Disp8MemShift=6|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegZMM|ZMMword|Unspecified|BaseIndex, RegZMM }
diff --git a/opcodes/i386-tbl.h b/opcodes/i386-tbl.h
index 9af048cc0c..1c402f5ab3 100644
--- a/opcodes/i386-tbl.h
+++ b/opcodes/i386-tbl.h
@@ -40861,8 +40861,8 @@ const insn_template i386_optab[] =
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 0, 0 } },
- { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
+ { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 1,
+ 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0 },
{ { { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
@@ -40895,8 +40895,8 @@ const insn_template i386_optab[] =
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 0, 0 } },
- { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
+ { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 1,
+ 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0 },
{ { { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -40922,23 +40922,6 @@ const insn_template i386_optab[] =
{ { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0,
0, 0, 0 } } } },
- { "vmovd", 2, 0x666E, None, 1,
- { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 1, 0, 0 } },
- { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
- 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 2, 0, 0, 0,
- 0, 0, 0, 0, 0 },
- { { { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0,
- 0, 0, 0 } },
- { { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0,
- 0, 0, 0 } } } },
{ "vmovd", 2, 0x667E, None, 1,
{ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -40956,23 +40939,6 @@ const insn_template i386_optab[] =
{ { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1,
0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0,
0, 0, 0 } } } },
- { "vmovd", 2, 0x667E, None, 1,
- { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 1, 0, 0 } },
- { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
- 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 2, 0, 0, 0,
- 0, 0, 0, 0, 0 },
- { { { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0,
- 0, 0, 0 } },
- { { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
- 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0,
- 0, 0, 0 } } } },
{ "vmovddup", 2, 0xf212, None, 1,
{ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
--
2.14.3
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 12:34 ` H.J. Lu
@ 2018-01-08 12:56 ` Jan Beulich
2018-01-08 13:08 ` H.J. Lu
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2018-01-08 12:56 UTC (permalink / raw)
To: H.J. Lu; +Cc: Binutils
>>> On 08.01.18 at 13:34, <hjl.tools@gmail.com> wrote:
> This is what I am checking in.
Thanks, yet I still have a point to make: the AVX vmovd templates
don't participate in SSE2AVX handling, hence continuing to allow
64-bit memory operands there doesn't look necessary. The SSE2AVX
pattern is a movd one.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory
2018-01-08 12:56 ` Jan Beulich
@ 2018-01-08 13:08 ` H.J. Lu
0 siblings, 0 replies; 16+ messages in thread
From: H.J. Lu @ 2018-01-08 13:08 UTC (permalink / raw)
To: Jan Beulich; +Cc: Binutils
On Mon, Jan 8, 2018 at 4:56 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 08.01.18 at 13:34, <hjl.tools@gmail.com> wrote:
>> This is what I am checking in.
>
> Thanks, yet I still have a point to make: the AVX vmovd templates
> don't participate in SSE2AVX handling, hence continuing to allow
> 64-bit memory operands there doesn't look necessary. The SSE2AVX
> pattern is a movd one.
Only allow 64-bit register operand with vmovd is kind of tricky. You can
give it a try.
--
H.J.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2018-01-08 13:08 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-08 1:18 [PATCH] x86: Properly encode vmovd with 64-bit memeory H.J. Lu
2018-01-08 8:48 ` Jan Beulich
2018-01-08 11:14 ` H.J. Lu
2018-01-08 11:22 ` H.J. Lu
2018-01-08 11:36 ` Jan Beulich
2018-01-08 11:49 ` H.J. Lu
2018-01-08 11:54 ` Jan Beulich
2018-01-08 11:57 ` H.J. Lu
2018-01-08 12:08 ` Jan Beulich
2018-01-08 11:39 ` Jan Beulich
2018-01-08 11:52 ` H.J. Lu
2018-01-08 12:13 ` Jan Beulich
2018-01-08 12:17 ` H.J. Lu
2018-01-08 12:34 ` H.J. Lu
2018-01-08 12:56 ` Jan Beulich
2018-01-08 13:08 ` H.J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).