Like for AVX512-FP16, there's not that many FP insns where going through
this table is easier / cheaper than using suitable macros. Utilize %XS
and %XD more to eliminate a fair number of table entries.
While doing this I noticed a few anomalies. Where lines get touched /
moved anyway, these are being addressed right here:
- vmovshdup used EXx for its 2nd operand, thus displaying seemingly
valid broadcast when EVEX.b is set with a memory operand; use
EXEvexXNoBcst instead just like vmovsldup already does
- vmovlhps used EXx for its 3rd operand, when all sibling entries use
EXq; switch to EXq there for consistency (the two differ only for
memory operands)
Like already indicated during review of the original submission, there's
really only very few insns where going through this table is easier /
cheaper than using suitable macros. Utilize %XH more and introduce
similar %XS and %XD (which subsequently can be used for further table
size reduction).
While there also switch to using oappend() in 'XH' macro processing.
Intel AVX512 FP16 instructions use maps 3, 5 and 6. Maps 5 and 6 use 3 bits
in the EVEX.mmm field (0b101, 0b110). Map 5 is for instructions that were FP32
in map 1 (0Fxx). Map 6 is for instructions that were FP32 in map 2 (0F38xx).
There are some exceptions to this rule. Some things in map 1 (0Fxx) with imm8
operands predated our current conventions; those instructions moved to map 3.
FP32 things in map 3 (0F3Axx) found new opcodes in map3 for FP16 because map3
is very sparsely populated. Most of the FP16 instructions share opcodes and
prefix (EVEX.pp) bits with the related FP32 operations.
Intel AVX512 FP16 instructions has new displacements scaling rules, please refer
to the public software developer manual for detail information.
gas/
2021-08-05 Igor Tsimbalist <igor.v.tsimbalist@intel.com>
H.J. Lu <hongjiu.lu@intel.com>
Wei Xiao <wei3.xiao@intel.com>
Lili Cui <lili.cui@intel.com>
* config/tc-i386.c (struct Broadcast_Operation): Adjust comment.
(cpu_arch): Add .avx512_fp16.
(cpu_noarch): Add noavx512_fp16.
(pte): Add evexmap5 and evexmap6.
(build_evex_prefix): Handle EVEXMAP5 and EVEXMAP6.
(check_VecOperations): Handle {1to32}.
(check_VecOperands): Handle CheckRegNumb.
(check_word_reg): Handle Toqword.
(i386_error): Add invalid_dest_and_src_register_set.
(match_template): Handle invalid_dest_and_src_register_set.
* doc/c-i386.texi: Document avx512_fp16, noavx512_fp16.
opcodes/
2021-08-05 Igor Tsimbalist <igor.v.tsimbalist@intel.com>
H.J. Lu <hongjiu.lu@intel.com>
Wei Xiao <wei3.xiao@intel.com>
Lili Cui <lili.cui@intel.com>
* i386-dis.c (EXwScalarS): New.
(EXxh): Ditto.
(EXxhc): Ditto.
(EXxmmqh): Ditto.
(EXxmmqdh): Ditto.
(EXEvexXwb): Ditto.
(DistinctDest_Fixup): Ditto.
(enum): Add xh_mode, evex_half_bcst_xmmqh_mode, evex_half_bcst_xmmqdh_mode
and w_swap_mode.
(enum): Add PREFIX_EVEX_0F3A08_W_0, PREFIX_EVEX_0F3A0A_W_0,
PREFIX_EVEX_0F3A26, PREFIX_EVEX_0F3A27, PREFIX_EVEX_0F3A56,
PREFIX_EVEX_0F3A57, PREFIX_EVEX_0F3A66, PREFIX_EVEX_0F3A67,
PREFIX_EVEX_0F3AC2, PREFIX_EVEX_MAP5_10, PREFIX_EVEX_MAP5_11,
PREFIX_EVEX_MAP5_1D, PREFIX_EVEX_MAP5_2A, PREFIX_EVEX_MAP5_2C,
PREFIX_EVEX_MAP5_2D, PREFIX_EVEX_MAP5_2E, PREFIX_EVEX_MAP5_2F,
PREFIX_EVEX_MAP5_51, PREFIX_EVEX_MAP5_58, PREFIX_EVEX_MAP5_59,
PREFIX_EVEX_MAP5_5A_W_0, PREFIX_EVEX_MAP5_5A_W_1,
PREFIX_EVEX_MAP5_5B_W_0, PREFIX_EVEX_MAP5_5B_W_1,
PREFIX_EVEX_MAP5_5C, PREFIX_EVEX_MAP5_5D, PREFIX_EVEX_MAP5_5E,
PREFIX_EVEX_MAP5_5F, PREFIX_EVEX_MAP5_78, PREFIX_EVEX_MAP5_79,
PREFIX_EVEX_MAP5_7A, PREFIX_EVEX_MAP5_7B, PREFIX_EVEX_MAP5_7C,
PREFIX_EVEX_MAP5_7D_W_0, PREFIX_EVEX_MAP6_13, PREFIX_EVEX_MAP6_56,
PREFIX_EVEX_MAP6_57, PREFIX_EVEX_MAP6_D6, PREFIX_EVEX_MAP6_D7
(enum): Add EVEX_MAP5 and EVEX_MAP6.
(enum): Add EVEX_W_MAP5_5A, EVEX_W_MAP5_5B,
EVEX_W_MAP5_78_P_0, EVEX_W_MAP5_78_P_2, EVEX_W_MAP5_79_P_0,
EVEX_W_MAP5_79_P_2, EVEX_W_MAP5_7A_P_2, EVEX_W_MAP5_7A_P_3,
EVEX_W_MAP5_7B_P_2, EVEX_W_MAP5_7C_P_0, EVEX_W_MAP5_7C_P_2,
EVEX_W_MAP5_7D, EVEX_W_MAP6_13_P_0, EVEX_W_MAP6_13_P_2,
(get_valid_dis386): Properly handle new instructions.
(intel_operand_size): Handle new modes.
(OP_E_memory): Ditto.
(OP_EX): Ditto.
* i386-dis-evex.h: Updated for AVX512_FP16.
* i386-dis-evex-mod.h: Updated for AVX512_FP16.
* i386-dis-evex-prefix.h: Updated for AVX512_FP16.
* i386-dis-evex-reg.h : Updated for AVX512_FP16.
* i386-dis-evex-w.h : Updated for AVX512_FP16.
* i386-gen.c (cpu_flag_init): Add CPU_AVX512_FP16_FLAGS,
and CPU_ANY_AVX512_FP16_FLAGS. Update CPU_ANY_AVX512F_FLAGS
and CPU_ANY_AVX512BW_FLAGS.
(cpu_flags): Add CpuAVX512_FP16.
(opcode_modifiers): Add DistinctDest.
* i386-opc.h (enum): (AVX512_FP16): New.
(i386_opcode_modifier): Add reqdistinctreg.
(i386_cpu_flags): Add cpuavx512_fp16.
(EVEXMAP5): Defined as a macro.
(EVEXMAP6): Ditto.
* i386-opc.tbl: Add Intel AVX512_FP16 instructions.
* i386-init.h: Regenerated.
* i386-tbl.h: Ditto.
With EVEX.W clear the instruction doesn't ignore the rounding mode, but
(like for other insns without rounding semantics) EVEX.b set causes #UD.
Hence the handling of EVEX.W needs to be done when processing
evex_rounding_64_mode, not at the decode stages.
Derive a new 64-bit testcase from the 32-bit one to cover the different
EVEX.W treatment in both cases.
Commit 6ff00b5e12 ("x86/Intel: correct permitted operand sizes for
AVX512 scatter/gather") brought the assembler side of AVX512 S/G insn
handling in line with AVX2's, but the disassembler side was forgotten.
This has the benefit of
- allowing to fold a number of table entries,
- rendering a few #define-s and enumerators unused.
When the VEX.L=1 decode matches that of both EVEX.L'L=1 and EVEX.L'L=2
(typically when all three are invalid) the (smaller) VEX table entry can
be reused by EVEX, instead of duplicating data. (Note that XM and XMM as
well as EXxmm_md and EXd are equivalent at least for the purposes here.)
The order of decodes influences the overall number of table entries.
Reduce table size quite a bit by first decoding few-alternatives
attributes common to all valid leaves.
This also adds a PREFIX_DATA 7531c61332 ("x86: simplify decode of
opcodes valid with (embedded) 66 prefix only") missed to apply to
vbroadcastf64x4.
Rdq, Rd, and MaskR can be replaced by Edq, Ed / Rm, and MaskE
respectively, as OP_R() doesn't enforce ModRM.mod == 3, and hence where
MOD matters but hasn't been decoded yet it needs to be anyway. (The case
of converting to Rm is temporary until a subsequent change.)
The only valid (embedded or explicit) prefix being the data size one
(which is a fairly common pattern), avoid going through prefix_table[].
Instead extend the "required prefix" logic to also handle PREFIX_DATA
alone in a table entry, now used to identify this case. This requires
moving the (adjusted) ->prefix_requirement logic ahead of the printing
of stray prefixes, as the latter needs to observe the new setting of
PREFIX_DATA in used_prefixes.
Also add PREFIX_OPCODE on related entries when previously there was
mistakenly no decode step through prefix_table[].
It was quite odd for the prior operand handling to have to clear this
flag for the actual operand handling to print nothing. Have the actual
operand handling determine whether the operand is actually present.
With this {d,q}_scalar_swap_mode become unused and hence also get dropped.
Unlike the earlier ones these also need their operands adjusted. Replace
the (mis-described: there's nothing "scalar" here) {b,w}_scalar_mode by
a single new mode, with the actual unit width controlled by EVEX.W.
The operands don't allow disambiguating the insn in 64-bit mode, and
hence suffixes need to be emitted not just in AT&T mode. Achieve this
by re-using %LQ while dropping PCMPESTR_Fixup().
Since we have these macros, there's no point having unnecessary table
depth.
VFPCLASSP{S,D} are now the first instance of using two %-prefixed
macros, which has pointed out a problem with the implementation. Instead
of using custom code in various case blocks, do the macro accumulation
centralized at the top of the main loop of putop(), and zap the
accumulated macros at the bottom of that loop once it has been
processed.
Just like their AVX counterparts do for VEX.L.
At this occasion also make EVEX.W have the same effect as VEX.W on the
printing of VPINSR{B,W}'s operands, bringing them also in sync with
VPEXTR{B,W}.
Unlike for the EVEX-encoded versions, the VEX ones failed to decode
VEX.W. Once the necessary adjustments are done, it becomes obvious that
the EVEX and VEX table entries for VCVTPS2PH are identical and can hence
be folded.
The duplication is not only space inefficient, but also risks entries
going out of sync (some of which that I became aware of while doing this
work will get addressed subsequently). Right here note that for
VGF2P8MULB this also addresses the prior lack of EVEX.W decoding (i.e. a
first example of out of sync entries).
This introduces EXxEVexR to some VEX templates, on the basis that this
operand is benign there and only relevant when EVEX encoding ends up
reaching these entries.
There's only a single user, that that one can do fine with the
alternative, as the "Vex" aspect of the other operand kind is meaningful
only on 3-operand insns.
While doing this I noticed that I didn't need to do the same adjustment
in the EVEX tables, and voilà - there was a bug, which gets fixed at the
same time (see the testsuite changes).
Along the lines of 4102be5cf9 ("x86: replace EXxmm_mdq by
EXVexWdqScalar"), but in the opposite direction, replace EXdScalar/
EXqScalar by EXxmm_md/EXxmm_mq respectively, rendering d_scalar_mode and
q_scalar_mode unused. The change is done this way to improve telling
apart operands affected here from ones using EXbScalar/EXwScalar, which
work sufficiently differently. Additionally this increases similarity
between several VEX-encoded insns and their EVEX-encoded counterparts.
For major opcodes allowing only packed FP kinds of operands, i.e. the
ones where legacy and AVX decoding uses the X macro, we can do so for
AVX512 as well, by attaching to the checking logic the "EVEX.W must
match presence of embedded 66 prefix" rule. (Encodings not following
this general pattern simply may not gain the PREFIX_OPCODE attribute.)
Note that testing of the thus altered decoding has already been put in
place by "x86: correct decoding of packed-FP-only AVX encodings".
This can also be at least partly applied to scalar-FP-only insns (i.e.
V{,U}COMIS{S,D}) as well as the vector-FP forms of insns also allowing
scalar encodings (e.g. VADDP{S,D}).
Take the opportunity and also fix EVEX-encoded VMOVNTP{S,D} as well as
to-memory forms of VMOV{L,H}PS and both forms of VMOV{L,H}PD to wrongly
disassemble with only register operands.
Just like their AVX counterparts they can utilize XMVexScalar /
EXdVexScalarS / EXqVexScalarS taking care of dropping the middle operand
for their memory forms.
I assume this mode was needed when EVEX.W handling wasn't really correct
yet for other than 64-bit mode. It's clearly not needed anymore. Its
elimination also allows dropping the EVEX.W split of VCVT{,U}SI2SS. (For
the record, the dropped mode would have been wrong if used in any table
entry not already guaranteeing EVEX.W=1.)
Break i386-dis-evex.h into small files such that each file is included
just once.
* i386-dis-evex.h: Break into ...
* i386-dis-evex-len.h: New file.
* i386-dis-evex-mod.h: Likewise.
* i386-dis-evex-prefix.h: Likewise.
* i386-dis-evex-reg.h: Likewise.
* i386-dis-evex-w.h: Likewise.
* i386-dis.c: Include i386-dis-evex-reg.h, i386-dis-evex-prefix.h,
i386-dis-evex.h, i386-dis-evex-len.h, i386-dis-evex-w.h and
i386-dis-evex-mod.h.
