aboutsummaryrefslogtreecommitdiff
path: root/opcodes/i386-opc.tbl
AgeCommit message (Collapse)AuthorFilesLines
2020-02-17x86: Remove CpuABM and add CpuPOPCNTH.J. Lu1-3/+5
AMD ABM has 2 instructions: popcnt and lzcnt. ABM CPUID feature bit has been reused for lzcnt and a POPCNT CPUID feature bit is added for popcnt which used to be the part of SSE4.2. This patch removes CpuABM and adds CpuPOPCNT. It changes ABM to enable both lzcnt and popcnt, changes SSE4.2 to also enable popcnt. gas/ * config/tc-i386.c (cpu_arch): Add .popcnt. * doc/c-i386.texi: Remove abm and .abm. Add popcnt and .popcnt. Add a tab before @samp{.sse4a}. opcodes/ * i386-gen.c (cpu_flag_init): Replace CpuABM with CpuLZCNT|CpuPOPCNT. Add CpuPOPCNT to CPU_SSE4_2_FLAGS. Add CPU_POPCNT_FLAGS. (cpu_flags): Remove CpuABM. Add CpuPOPCNT. * i386-opc.h (CpuABM): Removed. (CpuPOPCNT): New. (i386_cpu_flags): Remove cpuabm. Add cpupopcnt. * i386-opc.tbl: Replace CpuABM|CpuSSE4_2 with CpuPOPCNT on popcnt. Remove CpuABM from lzcnt. * i386-init.h: Regenerated. * i386-tbl.h: Likewise.
2020-02-17x86: fold certain VCVT{,U}SI2S{S,D} templatesJan Beulich1-21/+15
There don't really need to be separate Cpu64 and CpuNo64 templates for these. One small issue with this is that slightly strange code .intel_syntax noprefix .code16 .arch i286 .arch .avx vcvtsi2sd xmm0, xmm0, dword ptr [bx] vcvtsi2sd xmm0, xmm0, qword ptr [bx] vcvtsi2sd xmm0, xmm0, ebx vcvtsi2sd xmm0, xmm0, rbx now will match in behavior with the AVX512 counterparts in that not only the 2nd vcvtsi2sd won't assemble, but also the first. The last two, otoh, will continue to assemble fine (due to the lack of any memory operand size specifier). As a result, another way to make things behave more consistently would be to avoid the folding and add IgnoreSize to the CpuNo64 AVX512 variants. A 3rd way to do so would be to add Cpu386 to any such insn template. While doing this also make the usual cosmetic adjustments for the insns touched anyway. Additionally drop the redundant Cpu64 from the SAE forms of VCVT{,U}SI2SD - they won't assemble outside of 64-bit mode due to there not being anything to match the Reg64 operand.
2020-02-17x86: fold AddrPrefixOpReg templatesJan Beulich1-24/+15
There's no need to have separate Cpu64 and CpuNo64 templates: There already is special logic handling the attribute, and all that's needed is rejecting 16-bit address registers in 64-bit mode. Suppress suffix guessing and group all involved logic together, outside of suffix processing (arguably it doesn't even belong in process_suffix()). Also, since no AddrPrefixOpReg template permits any suffixes, move the No_*Suf specifiers for them to a central place. Along with this drop the no longer relevant NoRex64 from there.
2020-02-17x86/Intel: improve diagnostics for ambiguous VCVT* operandsJan Beulich1-13/+23
Conversions which shrink element size and which have a memory source can't be disambiguated between their 128- and 256-bit variants by looking at the register operand. "operand size mismatch", however, is a pretty misleading diagnostic. Generalize the logic introduced for VFPCLASSP{S,D} such that, with suitable similar adjustments to the respective templates, it'll cover these cases too. For VCVTNEPS2BF16 also fold the two previously separate AVX512VL templates to achieve the intended effect. This is then also accompanied by a respective addition to the inval-avx512f testcase.
2020-02-14Remove Intel syntax comments on movsx and movzxH.J. Lu1-3/+2
Since movsx and movzx are valid mnemonic in AT&T syntax, remove Intel syntax comments on movsx and movzx to avoid confusing other readers. * i386-opc.tbl (movsx): Remove Intel syntax comments. (movzx): Likewise.
2020-02-14x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZXJan Beulich1-12/+5
For these to get treatment consistent with other operand size checking the special logic shouldn't live in md_assemble(), but process_suffix(). And there's more logic involved than simply zapping the suffix. Note however that MOVS[BW]* and MOVZ[BW]* still won't be fully consistent, due to the objection to fold MOVS* templates just like was done for MOVZ* in c07315e0c6 ("x86: allow suffix-less movzw and 64-bit movzb"). Note further that it is against my own intentions to have MOVSX/MOVZX silently default to a byte source in AT&T mode. This should happen only when the destination register is a 16-bit one. In all other cases there is an ambiguity, and the user should be warned. But it was explicitly requested for this to be done in a way inconsistent with everything else. Note finally that the assembler change points out (and this patch fixes) a wrong Intel syntax test introduced by bc31405ebb2c ("x86-64: Properly encode and decode movsxd"): When source code specifies a 16-bit destination register, disassembly expectations shouldn't have been to find a 32-bit one.
2020-02-12x86: correct VFPCLASSP{S,D} operand size handlingJan Beulich1-2/+4
With AVX512VL disabled (e.g. when writing code for the Knights family of processors) these insns aren't ambiguous when used with a memory source, and hence should be accepted without suffix or operand size specifier. When AVX512VL is enabled, to be consistent with this as well as other ambiguous operand size handling it would seem better to just warn about the ambiguity in AT&T mode, and still default to 512-bit operands (on the assumption that the code may have been written without AVX512VL in mind yet), but it was requested to leave AT&T syntax mode alone here.
2020-02-12x86: fold two JMP templatesJan Beulich1-2/+1
Now that the AMD64 check in match_template() applies to 64-bit code only, the non-64-bit and the Amd64 template can be folded, as being otherwise compatible with one another. (Oddly enough the same doesn't apply to CALL, due to the suffixes it permits, while JMP doesn't allow for any.)
2020-02-12x86-64: Intel64 adjustments for insns dealing with far pointersJan Beulich1-11/+16
AMD and Intel differ in their handling of far indirect branches as well as LFS/LGS/LSS: AMD CPUs ignore REX.W while Intel ones honors it. (Note how the latter three were hybrids so far, while far branches were fully AMD-like.)
2020-02-11x86: drop ShortForm attributeJan Beulich1-95/+95
It is very simple to derive from other template properties, and hence there's little point wasting storage for it.
2020-02-11x86: drop stray ShortForm attributesJan Beulich1-6/+6
This attribute is meaningless when there are no operands to encode.
2020-02-10x86: Accept Intel64 only instruction by defaultH.J. Lu1-11/+15
Commit d835a58baae720 disabled sysenter/sysenter in 64-bit mode by default. By default, assembler should accept common, Intel64 only and AMD64 ISAs since there are no conflicts. gas/ PR gas/25516 * config/tc-i386.c (intel64): Renamed to ... (isa64): This. (match_template): Accept Intel64 only instruction by default. (i386_displacement): Updated. (md_parse_option): Updated. * c-i386.texi: Update -mamd64/-mintel64 documentation. * testsuite/gas/i386/i386.exp: Run x86-64-sysenter. Pass -mamd64 to x86-64-sysenter-amd. * testsuite/gas/i386/x86-64-sysenter.d: New file. opcodes/ PR gas/25516 * i386-gen.c (opcode_modifiers): Replace AMD64 and Intel64 with ISA64. * i386-opc.h (AMD64): Removed. (Intel64): Likewose. (AMD64): New. (INTEL64): Likewise. (INTEL64ONLY): Likewise. (i386_opcode_modifier): Replace amd64 and intel64 with isa64. * i386-opc.tbl (Amd64): New. (Intel64): Likewise. (Intel64Only): Likewise. Replace AMD64 with Amd64. Update sysenter/sysenter with Cpu64 and Intel64Only. Remove AMD64 from sysenter/sysenter. * i386-tbl.h: Regenerated.
2020-01-30x86-64: honor vendor specifics for near RETJan Beulich1-2/+4
While vendors agree about default operand size (64 bits) and hence unavilability of a 32-bit form, AMD honors a 16-bit operand size override (0x66) while Intel doesn't.
2020-01-30x86: drop further pointless/bogus DefaultSizeJan Beulich1-9/+9
- 64-bit CALL permitting just a single operand size doesn't need it. - FLDENV et al should never have had it. It remains suspicious that a number of 64-bit only insns continue to have the attribute, despite this being intended for .code16gcc handling only.
2020-01-27x86-64: Properly encode and decode movsxdH.J. Lu1-1/+3
movsxd is a 64-bit only instruction. It supports both 16-bit and 32-bit destination registers. Its AT&T mnemonic is movslq which only supports 64-bit destination register. There is also a discrepancy between AMD64 and Intel64 on movsxd with 16-bit destination register. AMD64 supports 32-bit source operand and Intel64 supports 16-bit source operand. This patch updates movsxd encoding and decoding to alow 16-bit and 32-bit destination registers. It also handles movsxd with 16-bit destination register for AMD64 and Intel 64. gas/ PR binutils/25445 * config/tc-i386.c (check_long_reg): Also convert to QWORD for movsxd. * doc/c-i386.texi: Add a node for AMD64 vs. Intel64 ISA differences. Document movslq and movsxd. * testsuite/gas/i386/i386.exp: Run PR binutils/25445 tests. * testsuite/gas/i386/x86-64-movsxd-intel.d: New file. * testsuite/gas/i386/x86-64-movsxd-intel64-intel.d: Likewise. * testsuite/gas/i386/x86-64-movsxd-intel64-inval.l: Likewise. * testsuite/gas/i386/x86-64-movsxd-intel64-inval.s: Likewise. * testsuite/gas/i386/x86-64-movsxd-intel64.d: Likewise. * testsuite/gas/i386/x86-64-movsxd-intel64.s: Likewise. * testsuite/gas/i386/x86-64-movsxd-inval.l: Likewise. * testsuite/gas/i386/x86-64-movsxd-inval.s: Likewise. * testsuite/gas/i386/x86-64-movsxd.d: Likewise. * testsuite/gas/i386/x86-64-movsxd.s: Likewise. opcodes/ PR binutils/25445 * i386-dis.c (MOVSXD_Fixup): New function. (movsxd_mode): New enum. (x86_64_table): Use MOVSXD_Fixup and movsxd_mode on movsxd. (intel_operand_size): Handle movsxd_mode. (OP_E_register): Likewise. (OP_G): Likewise. * i386-opc.tbl: Remove Rex64 and allow 32-bit destination register on movsxd. Add movsxd with 16-bit destination register for AMD64 and Intel64 ISAs. * i386-tbl.h: Regenerated.
2020-01-21x86: improve handling of insns with ambiguous operand sizesJan Beulich1-1/+1
Commit b76bc5d54e ("x86: don't default variable shift count insns to 8-bit operand size") pointed out a very bad case, but the underlying problem is, as mentioned on various occasions, much larger: Silently selecting a (nowhere documented afaict) certain default operand size when there's no "sizing" suffix and no suitable register operand(s) is simply dangerous (for the programmer to make mistakes). While in Intel syntax mode such mistakes already lead to an error (which is going to remain that way), AT&T syntax mode now gains warnings in such cases by default, which can be suppressed or promoted to an error if so desired by the programmer. Furthermore at least general purpose insns now consistently have a default applied (alongside the warning emission), rather than accepting some and refusing others. No warnings are (as before) to be generated for "DefaultSize" insns as well as ones acting on selector and other fixed-width values. For SYSRET, however, the DefaultSize needs to be dropped - it had been wrongly put there in the first place, as it's unrelated to .code16gcc (no stack accesses involved). As set forth as a prereq when I first mentioned this intended change a few years back, Linux as well as gcc have meanwhile been patched to avoid (emission of) ambiguous operands (and hence triggering of the new warning). Note that I think that in 64-bit mode IRET and far RET would better get a diagnostic too, as it's reasonably likely that a suffix-less instance really is meant to be a 64-bit one. But I guess I better make this a separate follow-on patch. Note further that floating point operations with integer operands are an exception for now: They continue to use short (16-bit) operands by default even in 32- and 64-bit modes. Finally note that while {,V}PCMPESTR{I,M} would, strictly speaking, also need to be diagnosed, with their 64-bit forms not being very useful I think it is better to continue to avoid warning about them (by way of them carrying IgnoreSize attributes).
2020-01-21x86: VCVTNEPS2BF16{X,Y} should permit broadcastingJan Beulich1-2/+2
Just like other VCVT*{X,Y} templates do, and to allow the programmer flexibility (might be relevant in particular when heavily macro-izing code), the two templates should also have Broadcast set, just like their X/Y-suffix-less counterparts. This in turn requires them to also have * Dword set on their memory operands, to cover the logic added to i386gen by 4a1b91eabbe7 ("x86: Expand Broadcast to 3 bits"), * RegXMM/RegYMM set on their source operands, to satisfy broadcast sizing logic in gas itself. Otherwise ATTSyntax templates wouldn't need such operand size attributes. While extending the test cases, also add Intel syntax broadcast forms without explicit size specifiers.
2020-01-17x86: Add {vex} pseudo prefixH.J. Lu1-0/+1
There are 2-byte VEX prefix and 3-byte VEX prefix. 2-byte VEX prefix can't encode all operands. By default, assembler tries 2-byte VEX prefix first. {vex3} can be used to force 3-byte VEX prefix. This patch adds {vex} pseudo prefix and keeps {vex2} for backward compatibility. gas/ * config/tc-i386.c (_i386_insn): Replace vex_encoding_vex2 with vex_encoding_vex. (parse_insn): Likewise. * doc/c-i386.texi: Replace {vex2} with {vex}. Update {vex} and {vex3} documentation. * testsuite/gas/i386/pseudos.s: Replace 3 {vex2} tests with {vex}. * testsuite/gas/i386/x86-64-pseudos.s: Likewise. opcodes/ * i386-opc.tbl: Add {vex} pseudo prefix. * i386-tbl.h: Regenerated.
2020-01-16x86: drop stale Vec_Imm4 related commentJan Beulich1-2/+0
I overlooked this in commit 9d3bf266fd ("x86: drop Vec_Imm4"), presumably because of the mis-spelling.
2020-01-16x86: add a few more missing VexWIGJan Beulich1-4/+4
Alternatively it could also be VexW0 (to match other SSE2AVX), but the VexW attribute shouldn't be left unset.
2020-01-16x86: VPEXTRQ/VPINSRQ are unavailable outside of 64-bit modeJan Beulich1-8/+8
The AVX512DQ patterns lacking a Cpu64 attribute made the memory operand forms accepted even outside of 64-bit mode, and this even without any {evex} pseudo-prefix (otherwise one could argue that this is an attempt to follow one possible, albeit somewhat odd, interpretation of the SDM wording to this effect). For consistency between the various involved templates drop the * (now) unnecessary IgnoreSize attributes * unnecessary (due to VexW1) Size64 attributes from VEX encoded forms * redundant (with Reg64) Qword operand attributes uniformly.
2020-01-09x86: SYSENTER/SYSEXIT are unavailable in 64-bit mode on AMDJan Beulich1-2/+4
The disassembler change is such that in default mode we'd disassemble the insns (for there not ebing any conflicts), but when AMD64 mode was explicitly requested, we'd show them as "(bad)".
2020-01-01Update year range in copyright notice of binutils filesAlan Modra1-1/+1
2019-12-27x86: consolidate Disp<NN> handling a littleJan Beulich1-18/+15
In memory operand addressing, which forms of displacement are permitted besides Disp8 is pretty clearly limited - outside of 64-bit mode, Disp16 or Disp32 only, depending on address size (MPX being special in not allowing Disp16), - in 64-bit mode, Disp32s or Disp64 without address size override, and solely Disp32 with one. Adjust assembler and i386-gen to match this, observing that templates already get adjusted before trying to match them against input depending on the presence of an address size prefix. This adjustment logic gets extended to all cases, as certain DispNN values should also be dropped when there's no such prefix. In fact behavior of the assembler, perhaps besides the exact diagnostics wording, should not differ between there being templates applicable to 64-bit and non-64-bit at the same time, or there being fully separate sets of templates, with their DispNN settings already reduced accordingly. This adjustment logic further gets guarded such that there wouldn't be and Disp<N> conversion based on address size prefix when this prefix doesn't control the width of the displacement (on branches other than absolute ones). These adjustments then also allow folding two MOV templates, which had been split between 64-bit and non-64-bits variants so far. Once in this area also - drop the bogus DispNN from JumpByte templates, leaving just the correct Disp8 there (compensated by i386_finalize_displacement() now setting Disp8 on their operands), - add the missing Disp32S to XBEGIN. Note that the changes make it necessary to temporarily mark a test as XFAIL; this will get taken care of by a subsequent patch. The failing parts are entirely bogus and will get replaced.
2019-12-04x86-64: accept 64-bit LFS/LGS/LSS forms with suffix or operand size specifierJan Beulich1-3/+3
Since we accept these without suffix / operand size specifier, we should also do so with one. (The fact that we unilaterally accept these, other than far branches, rather than limiting them to Intel64 mode, will be taken care of later on.) Also take the opportunity and make sure "lfs <reg>, tbyte ptr <mem>" et al get rejected outside of 64-bit mode. This became broken by dc2be329b950 ("i386: Only check suffix in instruction mnemonic"). Furthermore cover lgdt et al in the Intel syntax handling as well, which continued to work after said commit just by coincidence.
2019-12-04x86: drop some stray/bogus DefaultSizeJan Beulich1-5/+5
Insns permitting only GPR operands (and hence implicit sizing when there's no suffix) don't ever have their DefaultSize attribute inspected, so it shouldn't be there in the first place. Additionally XBEGIN is like JMP, not CALL, and hence shouldn't be converted to 32-bit operand size in .code16gcc mode. While the same is true for SYSRET, it permitting more than one suffix makes it FLDENV- like, and hence rather than dropping the attribute, for now add it to the exclusion list to avoid it getting an operand size prefix emitted in .code16gcc mode. (This will be dealt with later, perhaps together with FLDENV and friends.)
2019-11-14x86: drop redundant SYSCALL/SYSRET templatesJan Beulich1-2/+0
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'".
2019-11-14x86: fold individual Jump* attributes into a single Jump oneJan Beulich1-0/+5
..., taking just 3 bits instead of 5. No two of them are used together.
2019-11-14x86: make JumpAbsolute an insn attributeJan Beulich1-10/+10
... instead of an operand one: There's only ever one operand here anyway.
2019-11-14x86: make AnySize an insn attributeJan Beulich1-22/+22
... 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.
2019-11-12x86: fold EsSeg into IsStringJan Beulich1-15/+18
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.
2019-11-12x86: eliminate ImmExt abuseJan Beulich1-20/+28
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.
2019-11-12x86: introduce operand type "instance"Jan Beulich1-0/+4
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.
2019-11-08i386: Only check suffix in instruction mnemonicH.J. Lu1-2/+2
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.
2019-11-08x86: convert RegMask and RegBND from bitfield to enumeratorJan Beulich1-0/+4
This is to further shrink the operand type representation.
2019-11-08x86: convert RegSIMD and RegMMX from bitfield to enumeratorJan Beulich1-3/+4
This is to further shrink the operand type representation.
2019-11-08x86: convert Control/Debug/Test from bitfield to enumeratorJan Beulich1-0/+4
This is to further shrink the operand type representation.
2019-11-08x86: convert SReg from bitfield to enumeratorJan Beulich1-0/+2
This is to further shrink the operand type representation.
2019-11-08x86: introduce operand type "class"Jan Beulich1-5/+5
Many operand types, in particular the various kinds of registers, 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.
2019-11-07x86: support further AMD Zen2 instructionsJan Beulich1-0/+12
Both RDPRU and MCOMMIT have been publicly documented meanwhile: https://www.amd.com/system/files/TechDocs/24594.pdf.
2019-11-07x86/Intel: drop IgnoreSize from operand-less MOVSD/CMPSD againJan Beulich1-2/+2
These were mistakenly added by d241b91073 ("x86/Intel: correct MOVSD and CMPSD handling"). This addresses part of PR/gas 25167.
2019-10-30x86: re-do "shorthand" handlingJan Beulich1-0/+12
Now that the opcode table gets preprocessed, undo parts of commit dc821c5f9a ("x86: replace Reg8, Reg16, Reg32, and Reg64"): Have the preprocessor handle the expansion there, while making the expansions explicit in i386-gen and the register table.
2019-10-30x86: drop stray WJan Beulich1-6/+6
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).
2019-10-07x86/Intel: correct MOVSD and CMPSD handlingJan Beulich1-4/+4
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.
2019-09-20x86-64: fix handling of PUSH/POP of segment registerJan Beulich1-2/+4
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.
2019-08-07x86: drop stray FloatMFJan Beulich1-7/+7
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.
2019-07-16x86: make RegMem an opcode modifierJan Beulich1-35/+38
... 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.
2019-07-16x86: fold SReg{2,3}Jan Beulich1-10/+6
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.
2019-07-01x86: drop Vec_Imm4Jan Beulich1-4/+4
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).
2019-07-01x86: limit ImmExt abuseJan Beulich1-42/+42
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.