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.
gas/
PR gas/23665
* testsuite/gas/i386/avx-scalar-intel.d: Updated.
* testsuite/gas/i386/avx-scalar.d: Likewise.
* testsuite/gas/i386/x86-64-avx-scalar-intel.d: Likewise.
* testsuite/gas/i386/x86-64-avx-scalar.d: Likewise.
opcodes/
PR gas/23665
* i386-dis.c (vex_len_table): Update VEX_LEN_0F7E_P_1 and
VEX_LEN_0FD6_P_2 entries.
* i386-opc.tbl: Set Vex=1 on VEX.128 only vmovq.
* i386-tbl.h: Regenerated.
Add VEXWIG, defined as 3, to indicate that the VEX.W/EVEX.W bit is
ignored by such VEX/EVEX instructions, aka WIG instructions. Set
VexW=3 on VEX/EVEX WIG instructions. Update assembler to check
VEXWIG when setting the VEX.W bit.
gas/
PR gas/23642
* config/tc-i386.c (build_vex_prefix): Check VEXWIG when setting
the VEX.W bit.
(build_evex_prefix): Check VEXWIG when setting the EVEX.W bit.
opcodes/
PR gas/23642
* i386-opc.h (VEXWIG): New.
* i386-opc.tbl: Set VexW=3 on VEX/EVEX WIG instructions.
* i386-tbl.h: Regenerated.
Just like other insns having byte and word forms, these can also make
use of the W modifier, which at the same time allows simplifying some
other code a little bit.
Various moves come in load and store forms, and just like on the GPR
and FPU sides there would better be only one pattern. In some cases this
is not feasible because the opcodes are too different, but quite a few
cases follow a similar standard scheme. Introduce Opcode_SIMD_FloatD and
Opcode_SIMD_IntD, generalize handling in operand_size_match() (reverse
operand handling there simply needs to match "straight" operand one),
and fix a long standing, but so far only latent bug with when to zap
found_reverse_match.
Also once again drop IgnoreSize where pointlessly applied to templates
touched anyway as well as *word when redundant with Reg*.
There are separate CPUID feature bits for fxsave/fxrstor and cmovCC
instructions. This patch adds CpuCMOV and CpuFXSR to replace Cpu686
on corresponding instructions.
gas/
* config/tc-i386.c (cpu_arch): Add .cmov and .fxsr.
(cpu_noarch): Add nocmov and nofxsr.
* doc/c-i386.texi: Document cmov and fxsr.
opcodes/
* i386-gen.c (cpu_flag_init): Add CpuCMOV and CpuFXSR to
CPU_I686_FLAGS. Add CPU_CMOV_FLAGS, CPU_FXSR_FLAGS,
CPU_ANY_CMOV_FLAGS and CPU_ANY_FXSR_FLAGS.
(cpu_flags): Add CpuCMOV and CpuFXSR.
* i386-opc.tbl: Replace Cpu686 with CpuFXSR on fxsave, fxsave64,
fxrstor and fxrstor64. Replace Cpu686 with CpuCMOV on cmovCC.
* i386-init.h: Regenerated.
* i386-tbl.h: Likewise.
There's no insn allowing ZEROING_MASKING alone. Re-purpose its value for
handling the not uncommon case of insns allowing either form of masking
with register operands, but only merging masking with a memory operand.
Just like for their AVX counterparts and CVTSI2S{D,S}, a memory source
here is ambiguous and hence
- in source files should be qualified with a suitable suffix or operand
size specifier (not doing so is an error in Intel mode, and will gain
a diagnostic in AT&T mode in the future),
- in disassembly should be properly suffixed (the Intel operand size
specifiers were emitted correctly already).
When multiple (here: two) forms of an insn take different width inputs
but produce identical size outputs (here: RegXMM), the templates can be
combined.
Also drop IgnoreSize (and the now redundant size specifiers) wherever
applicable.
These are special because they may not have a register operand to derive
the vector length from, which requires to also deal with the braodcast
case when determining vector length in build_evex_prefix().
Also drop IgnoreSize (and the now redundant size specifiers) from their
suffixed counterparts.
Instead of expanding macro-like constructs in i386-gen, have the C pre-
processor do this for us. Besides being a prerequisite for the next
template folding steps, this also paves the way for removing various
hidden dependencies between #define-s in i386-opc.h and plain literal
numbers used in i386-opc.tbl.
The #undef of None is solely to leave the generated i386-tbl.h entirely
unchanged.
After
commit 1b54b8d7e4
Author: Jan Beulich <jbeulich@novell.com>
Date: Mon Dec 18 09:36:14 2017 +0100
x86: fold RegXMM/RegYMM/RegZMM into RegSIMD
... qualified by their respective sizes, allowing to drop FirstXmm0 at
the same time.
folded RegXMM, RegYMM and RegZMM into RegSIMD, it's no longer impossible
to distinguish if Xmmword can represent a memory reference when operand
specification contains SIMD register. For example, template operands
specification like these
RegXMM|...|Xmmword|...
and
RegXMM|...
The Xmmword bitfield is always set by RegXMM which is represented by
"RegSIMD|Xmmword". This patch splits each of vcvtps2qq, vcvtps2uqq,
vcvttps2qq and vcvttps2uqq into 2 templates: one template only has
RegXMM source operand and the other only has mempry source operand.
gas/
PR gas/23418
* testsuite/gas/i386/xmmword.s: Add tests for vcvtps2qq,
vcvtps2uqq, vcvttps2qq and vcvttps2uqq.
* testsuite/gas/i386/xmmword.l: Updated.
opcodes/
PR gas/23418
* i386-opc.h (Byte): Update comments.
(Word): Likewise.
(Dword): Likewise.
(Fword): Likewise.
(Qword): Likewise.
(Tbyte): Likewise.
(Xmmword): Likewise.
(Ymmword): Likewise.
(Zmmword): Likewise.
* i386-opc.tbl: Split vcvtps2qq, vcvtps2uqq, vcvttps2qq and
vcvttps2uqq.
* i386-tbl.h: Regenerated.
Architecturally, MONITOR's and MONITORX'es memory operand is a 16- or
32-bit register outside of 64-bit mode, and a 64- or 32-bit register
inside 64-bit mode. The other register operands, including all of them
for MWAIT and MWAITX, are uniformly 32-bit, irrespective of mode. Retain
the original 64-bit MONITOR{,X} templates for compatibility only, and
fold the MWAIT{,X} ones.
First of all there's no point in having separate Cpu386 templates - the
respective SReg3 registers can't be specified for pre-386 anyway; see
parse_real_register().
And then we can also make use of D here for the memory forms of the
insn. This cannot be done for the non-64bit GPR forms because of the
IgnoreSize that cannot be dropped from the to-SREG variant.
H.J. Lu
Jan Beulich