These all follow an almost common pattern, again with the exception of
being commutative, which can be easily taken care of.
Note that, as an intended side effect (and in fact one of the reason to
introduce templates), AVX long-form pseudo-ops get introduced alongside
the already existing AVX512 ones.
In order to reduce redundancy as well as the chance of things going out
of sync (see a later patch for an example), make the opcode table
generator capable of recognizing and expanding templated templates. Use
the new capability for compacting the general purpose conditional insns.
Presumably as a result of various changes over the last several months,
and - for some of them - with a generalization of logic in
match_mem_size() plus mirroring of this generalization into the
broadcast handling logic of check_VecOperands(), various register-only
templates can be foled into their respective memory forms. This in
particular then also allows dropping a few more instances of IgnoreSize.
Even after commit dc2be329b9 ("i386: Only check suffix in instruction
mnemonic"), by which many of its uses have become unnecessary (some were
unnecessary even before), IgnoreSize is still used for various slightly
different purposes:
- to suppress emission of an operand size prefix,
- in Intel syntax mode to zap "derived" suffixes in certain cases and to
skip certain checks of remaining "derived" suffixes,
- to suppress ambiguous operand size / missing suffix diagnostics,
- for prefixes to suppress the "stand-alone ... prefix" warning.
Drop entirely unnecessary ones and where possible also replace instances
by the more focused (because of having just a single purpose) NoRex64.
To further restrict when IgnoreSize is needed, also generalize the logic
when to skip a template because of a present or derived L or Q suffix,
by skipping immediate operands. Additionally consider mask registers and
VecSIB there.
Note that for the time being the attribute needs to be kept in place on
MMX/SSE/etc insns (but not on VEX/EVEX encoded ones unless an operand
template of them allows for only non-SIMD-register actuals) allowing for
Dword operands - the logic when to emit a data size prefix would need
further adjustment first.
Note also that the memory forms of {,v}pinsrw get their permission for
an L or Q suffix dropped. I can only assume that it being this way was a
cut-and-paste mistake from the register forms, as the latter
specifically have NoRex64 set, and the {,v}pextrw counterparts don't
allow these suffixes either.
Convert VexW= again to their respective VexW* on lines touched anyway.
As of commit dc2be329b9 ("i386: Only check suffix in instruction
mnemonic") these have been accepted even with "qword ptr" operand size
specifier, but in 64-bit mode they're now wrongly having a REX prefix
(with REX.W set) emitted in this case. These aren't Intel syntax
mnemonics, so rather than fixing code generation, let's simply reject
them. As a result, the Qword attribute can then be dropped, too.
When the template specifies any of the possible VexW settings, we can
use this instead of a separate NoRex64 to suppress the setting of REX_W.
Note that this ends up addressing an inconsistency between VEX- and
EVEX-encoded VEXTRACTPS, VPEXTR{B,W}, and VPINSR{B,W} - while the former
avoided setting VEX.W, the latter pointlessly set EVEX.W when there is a
64-bit GPR operand. Adjust the testcase to cover both cases.
Convert VexW= to their respective VexW* on lines touched anyway.
It is almost entirely redundant with Size64, and the sole case (CRC32)
where direct replacement isn't possible can easily be taken care of in
another way.
For proper code generation in 16-bit mode (or to avoid the "same type of
prefix used twice" diagnostic there), IgnoreSize is needed on certain
templates allowing for just 32-(and maybe 64-)bit operands.
Beyond adding tests for the previously broken cases, also add ones for
the previously working cases where IgnoreSize is needed for the same
reason (leaving out MPX for now, as that'll require an assembler change
first). Some minor adjustments to tests get done such that re-use of the
same code for 16-bit code generation testing becomes easier.
Allowing 64-bit registers is misleading here: Elsewhere these get allowed
when there's no difference between either variant, because of 32-bit
destination registers having their upper halves zeroed in 64-bit mode.
Here, however, they're source registers, and hence specifying 64-bit
registers would lead to the ambiguity of whether the upper 32 bits
actually matter.
Additionally, for proper code generation in 16-bit mode, IgnoreSize is
needed on both.
And finally, just like for e.g. MONITOR/MWAIT, add variants with all
input registers explicitly specified.
According to gas manual, suffix in instruction mnemonics isn't always
required:
When there is no sizing suffix and no (suitable) register operands to
deduce the size of memory operands, with a few exceptions and where long
operand size is possible in the first place, operand size will default
to long in 32- and 64-bit modes.
This includes cvtsi2sd, cvtsi2ss, vcvtsi2sd, vcvtsi2ss, vcvtusi2sd and
vcvtusi2ss. Since they are used in GCC 8 and older GCC releases, they
must be allowed without suffix in AT&T syntax.
gas/
PR gas/25622
* testsuite/gas/i386/i386.exp: Run x86-64-default-suffix and
x86-64-default-suffix-avx.
* testsuite/gas/i386/noreg64.s: Remove cvtsi2sd, cvtsi2ss,
vcvtsi2sd, vcvtsi2ss, vcvtusi2sd and vcvtusi2ss entries.
* testsuite/gas/i386/noreg64.d: Updated.
* testsuite/gas/i386/noreg64.l: Likewise.
* testsuite/gas/i386/x86-64-default-suffix-avx.d: New file.
* testsuite/gas/i386/x86-64-default-suffix.d: Likewise.
* testsuite/gas/i386/x86-64-default-suffix.s: Likewise.
opcodes/
PR gas/25622
* i386-opc.tbl: Add IgnoreSize to cvtsi2sd, cvtsi2ss, vcvtsi2sd,
vcvtsi2ss, vcvtusi2sd and vcvtusi2ss for AT&T syntax.
* i386-tbl.h: Regenerated.
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.
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.
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.
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.
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.
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 bc31405ebb ("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.
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.
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.)
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.)
Commit d835a58baa 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.
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.
- 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.
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.
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).
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 4a1b91eabb ("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.
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.
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)".
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.
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
dc2be329b9 ("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.
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.)
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.
