The Cpu64 forms are no different in their attributes except for the CPU
flags; there's no need to key these off of anything other than
CpuSYSCALL even for the 64-bit forms. Dropping these improves the
diagnostic on SYSRETQ used in 32-bit code from "unsupported instruction
`sysret'" to "invalid instruction suffix for `sysret'".
... instead of an operand one. Which operand it applies to can be
determined from other operand properties, but as it turns out the only
place it is actually used at doesn't even need further qualification.
EsSeg (a per-operand bit) is used with IsString (a per-insn attribute)
only. Extend the attribute to 2 bits, thus allowing to encode
- not a string insn,
- string insn with neither operand requiring use of %es:,
- string insn with 1st operand requiring use of %es:,
- string insn with 2nd operand requiring use of %es:,
which covers all possible cases, allowing to drop EsSeg.
The (transient) need to comment out the OTUnused #define did uncover an
oversight in the earlier OTMax -> OTNum conversion, which is being taken
care of here.
Drop the remaining instances left in place by commit c3949f432f ("x86:
limit ImmExt abuse), now that we have a way to specify specific GPRs.
Take the opportunity and also introduce proper 16-bit forms of
applicable SVME insns as well as 1-operand forms of CLZERO.
Special register "class" instances can't be combined with one another
(neither in templates nor in register entries), and hence it is not a
good use of resources (memory as well as execution time) to represent
them as individual bits of a bit field.
Furthermore the generalization becoming possible will allow
improvements to the handling of insns accepting only individual
registers as their operands.
We should check suffix in instruction mnemonic when matching instruction.
In Intel syntax, normally we check for memory operand size. But the same
mnemonic with 2 different encodings can have the same memory operand
size and i.suffix is set to LONG_DOUBLE_MNEM_SUFFIX from memory operand
size in Intel syntax to distinguish them. When there is no suffix in
mnemonic, we check LONG_DOUBLE_MNEM_SUFFIX in i.suffix for mnemonic
suffix.
gas/
PR gas/25167
* config/tc-i386.c (match_template): Don't check instruction
suffix set from operand.
* testsuite/gas/i386/code16.d: New file.
* testsuite/gas/i386/code16.s: Likewise.
* testsuite/gas/i386/i386.exp: Run code16.
* testsuite/gas/i386/x86-64-branch-4.l: Updated.
opcodes/
PR gas/25167
* i386-opc.tbl: Remove IgnoreSize from cmpsd and movsd.
* i386-tbl.h: Regenerated.
The flag is used to indicate opcodes which can be switched between byte
and word/dword/qword forms (in a "canonical" way). Obviously it's quite
odd then to see it on insns not allowing for byte operands in the first
place. As a result the opcode bytes need to be adjusted accordingly,
which includes comparisons done in optimize_encoding().
To make re-introduction of such issues less likely have i386-gen
diagnose it (in a generally non-fatal way for now).
First and foremost the EsSeg attribute was misplaced for CMPSD. Then
both it and MOVSD were lacking Dword on both of their operands.
Finally string insns with multiple operands and requiring use of ES:
had the wrong operand number reported in the diagnostic.
Commit 21df382b91 ("x86: fold SReg{2,3}") went too far: Folding 64-bit
PUSH/POP templates into non-64-bit ones isn't correct, due to the
different operand widths, and hence suffixes permitted. Restore the
separate templates.
Add tests of PUSH/POP with q suffix and %fs/%gs operands to the
testsuite. While doing so also add PUSHF/POPF ones _without_ suffix.
The flag is supposed to be used in templates which allow for both a
"short" and a "long" format memory operand. Drop it from templates not
matching this pattern. In the control/status word cases it was (ab)used
in place of the intended IgnoreSize.
... instead of an operand type bit: It's an insn property, not an
operand one. There's just one actual change to be made to the
templates: Most are now required to have the (unswapped) destination go
into ModR/M.rm, so VMOVD template needs its opcode adjusted accordingly
and its operands swapped. {,V}MOVS{S,D}, otoh, are left alone in this
regard, as otherwise generated code would differ from what we've been
producing so far (which I don't think is wanted).
Take the opportunity and add a missing IgnoreSize to pextrb (leading to
an error in 16-bit mode), and take the liberty to once again drop stray
IgnoreSize attributes from lines changed and neighboring related ones.
They're the only exception to there generally being no mix of register
kinds possible in an insn operand template, and there being two bits per
operand for their representation is also quite wasteful, considering the
low number of uses. Fold both bits and deal with the little bit of
fallout.
Also take the liberty and drop dead code trying to set REX_B: No segment
register has RegRex set on it.
Additionally I was quite surprised that PUSH/POP with the permitted
segment registers is not covered by the test cases. Add the missing
pieces.
It is pretty wasteful to have a per-operand flag which is used in
exactly 4 cases. It can be relatively easily replaced, and by doing so
I've actually found some dead code to remove at the same time (there's
no case of ImmExt set at the same time as Vec_Imm4).
In quite a few cases ImmExt gets used when there's not really any
immediate, but rather a degenerate ModR/M byte. ENCL{S,U} show how this
case is supposed to be dealt with. Eliminate most abuses, leaving in
place (for now) only ones where process_immext() is involved.
It seems to be not uncommon for people to use AND or OR in this form for
just setting the status flags. TEST, which doesn't write to any
register other than EFLAGS, ought to be preferred. Make the change only
for -O2 and above though, at least for now.
When they're in the 0F opcode space, swapping their source operands may
allow switching from 3-byte to 2-byte VEX prefix encoding. Note that NaN
behavior precludes us doing so for many packed and scalar floating point
insns; such an optimization would need to be done by the compiler
instead in this case, when it knows that NaN-s have undefined behavior
anyway.
While for explicitly specified AVX/AVX2 insns the optimization (for now
at least) gets done only for -O2 and -Os, it is utilized by default in
SSE2AVX mode, as there we're re-writing the programmer's specified insns
anyway.
Rather than introducing a new attribute flag, the change re-uses one
which so far was meaningful only for EVEX-encoded insns.
As long as there's no write mask as well as no broadcast, and as long
as the scaled Disp8 wouldn't result in a shorter EVEX encoding, encode
VPAND{D,Q}, VPANDN{D,Q}, VPOR{D,Q}, and VPXOR{D,Q} acting on only the
lower 16 XMM/YMM registers using their VEX equivalents with -O1.
Also take the opportunity and avoid looping twice over all operands
when dealing with memory-with-displacement ones.
While the ISA extensions doc suggests them to be made available just
like the SDM does for the PCLMULQDQ ISA extension, these weren't added
when supposrt for the new extension was introduced.
Also make sure the 64-bit non-AVX512 test actually tests VEX encodings,
not EVEX ones.
In commit dc821c5f9a ("x86: replace Reg8, Reg16, Reg32, and Reg64") I
apparently blindly copied the original register/memory templates into
separate ones, in particular without removing the Disp8MemShift which
are applicable to templates with memory operands only.
MOVNTI was wrongly assembled with a 66h prefix. Add IgnoreSize to
address this. It and the scalar to/from integer conversion insns also
were also wrongly using Ev / Gv, leading to 16-bit register names being
printed when 32-bit ones were meant.
Clone the 32-bit SSE2 test to cover both assembler and disassembler.
For AVX512 instructions with Disp8ShiftVL and Broadcast, we may need to
add CheckRegSize to check if broadcast matches the destination register
size.
gas/
PR gas/24625
* testsuite/gas/i386/inval-avx512f.s: Add tests for AVX512_BF16
instructions with invalid broadcast.
* testsuite/gas/i386/x86-64-inval-avx512f.s: Likewise.
* testsuite/gas/i386/inval-avx512f.l: Updated.
* testsuite/gas/i386/x86-64-inval-avx512f.l: Likewise.
opcodes/
PR gas/24625
* i386-opc.tbl: Add CheckRegSize to AVX512_BF16 instructions with
Disp8ShiftVL.
* i386-tbl.h: Regenerated.
1. Use single entry for vcvtne2ps2bf16 and vdpbf16ps with Disp8ShiftVL.
2. Use 5 entries, instead of 8, for vcvtneps2bf16.
* i386-opc.tbl: Consolidate AVX512 BF16 entries.
* i386-init.h: Regenerated.
PEXTR{B,W} and PINSR{B,W}, just like for AVX512BW, are WIG, no matter
that the SDM uses a nonstandard description of that fact.
PEXTRD, even with EVEX.W set, ignores that bit outside of 64-bit mode,
just like its AVX counterpart.
Many VEX-/EVEX-encoded instructions accessing GPRs become WIG outside of
64-bit mode. The respective templates should specify neither VexWIG nor
VexW0, but instead the setting of the bit should be determined from
- REX.W in 64-bit mode,
- the setting established through -mvexwig= / -mevexwig= otherwise.
This implies that the evex-wig2 testcase needs to go away, as being
wrong altogether.
A few test additions desirable here will only happen in later patches,
as the disassembler needs adjustments first.
Once again SSE2AVX templates are left alone, for it being unclear what
the behavior there should be.
Quite a few templates were marked LIG while really the insns aren't.
Introduce descriptive shorthands once again, instead of continuing to
use the less legible original forms.
The 0F C5 encoding is indeed a load type one (just that memory operands
are not permitted), while the 0F 3A 15 encoding is obviously a store.
Allow the pseudo prefixes to be used to select between them.
Also move (without any change) the secondary AVX512BW templates next to
the primary one.
Commits 6865c0435a ("x86: Support VEX/EVEX WIG encoding") and 6fa52824c3
("x86: Replace VexW=3 with VexWIG") omitted quite a few templates, oddly
enough in some cases despite testcases getting added (which then were
recorded with wrong expected output).
Also adjust VPMAXUB's attributes in the AVX512BW case to match ordering
of that of neighboring templates.
For the moment SSE2AVX templates are left alone, as it isn't clear
whether they were intentionally left untouched by the original commits
(the descriptions don't say either way).
In this context I question the decision in commit 0375113302 ("x86: Add
-mvexwig=[0|1] option to assembler") to move the logic to determine the
value of the W bit ahead of the decision whether to use 2-byte VEX:
While I can see this as one possible interpretation of -mvexwig=, the
other alternative (setting the value of the bit only if it actually
exists in the encoding) looks as reasonable to me, and perhaps even more
in line with us generally trying to pick the shortest encoding.
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.
Jan Beulich
H.J. Lu
Jan Beulich
Xuepeng Guo
Alan Modra