[X86] Ignore REX prefixes not immediately before opcode (#117299)

The Intel X86 Architecture Manual says the following:

> A REX prefix is ignored, as are its individual bits, when it is not
need

[X86] Ignore REX prefixes not immediately before opcode (#117299)

The Intel X86 Architecture Manual says the following:

> A REX prefix is ignored, as are its individual bits, when it is not
needed
> for an instruction or when it does not immediately precede the opcode
byte or
> the escape opcode byte (0FH) of an instruction for which it is needed.
This
> has the implication that only one REX prefix, properly located, can
affect an
> instruction.

We currently do not handle these cases in the disassembler, leading to
incorrect disassembly. This patch rectifies the situation by treating
REX prefixes as standard prefixes rather than only expecting them before
the Opcode.

The motivating test case added as a test was fuzzer generated.

show more ...

[X86] Switch to the new symbol visibility macros (#109982)

Switch LLVMInitialize* functions to new the symbol visibility macros
that will work for windows.
This is part of the work to enable LLVM_

[X86] Switch to the new symbol visibility macros (#109982)

Switch LLVMInitialize* functions to new the symbol visibility macros
that will work for windows.
This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows.

show more ...

[X86][AMX] Support AMX-TRANSPOSE (#113532)

Ref.: https://cdrdv2.intel.com/v1/dl/getContent/671368

[X86][AVX10.2] Support YMM rounding new instructions (#101825)

Ref.: https://cdrdv2.intel.com/v1/dl/getContent/828965

Reland "[X86][AVX10.2] Support AVX10.2 option and VMPSADBW/VADDP[D,H,S] new instructions (#101452)" (#101616)

Ref.: https://cdrdv2.intel.com/v1/dl/getContent/828965

Revert "[X86][AVX10.2] Support AVX10.2 option and VMPSADBW/VADDP[D,H,S] new instructions" (#101612)

Reverts llvm/llvm-project#101452

There are several buildbot failed. Revert first.

[X86][AVX10.2] Support AVX10.2 option and VMPSADBW/VADDP[D,H,S] new instructions (#101452)

Ref.: https://cdrdv2.intel.com/v1/dl/getContent/828965

[X86][MC] Not decode 0xf3 as rep prefix if it's right before REX2

This fixes https://github.com/llvm/llvm-project/issues/95412

[X86][MC] Support encoding/decoding for APX CCMP/CTEST (#83863)

APX assembly syntax recommendations:
https://cdrdv2.intel.com/v1/dl/getContent/817241

NOTE:
The change in llvm/tools/llvm-exege

[X86][MC] Support encoding/decoding for APX CCMP/CTEST (#83863)

APX assembly syntax recommendations:
https://cdrdv2.intel.com/v1/dl/getContent/817241

NOTE:
The change in llvm/tools/llvm-exegesis/lib/X86/Target.cpp is for test
LLVM ::
tools/llvm-exegesis/X86/latency/latency-SETCCr-cond-codes-sweep.s

For `SETcc`, llvm-exegesis would randomly choose 1 other instruction to
test with `SETcc`, after selecting the instruction, llvm-exegesis would
check if the operand is initialized and valid, if not
`randomizeTargetMCOperand` would choose a value for invalid operand, it
misses support for condition code operand, which cause the flaky failure
after `CCMP` supported.

llvm-exegesis can choose `CCMP` without specifying ccmp feature b/c it
use `MCSubtarget` and only16/32/64 bit is considered.
llvm-exegesis doesn't choose other instructions b/c requirement in
`hasAliasingRegistersThrough`: the instruction should use GPR (defined
by `SETcc`) and define `EFLAGS` (used by `SETcc`).

show more ...

[X86][MC] Reject out-of-range control and debug registers encoded with APX (#82584)

Fixes #82557. APX specification states that the high bits found in REX2
used to encode GPRs can also be used to e

[X86][MC] Reject out-of-range control and debug registers encoded with APX (#82584)

Fixes #82557. APX specification states that the high bits found in REX2
used to encode GPRs can also be used to encode control and debug
registers, although all of them will #UD. Therefore, when disassembling
we reject attempts to create control or debug registers with a value of
16 or more.

See page 22 of the
[specification](https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html):

> Note that the R, X and B register identifiers can also address non-GPR
register types, such as vector registers, control registers and debug
registers. When any of them does, the highest-order bits REX2.R4,
REX2.X4 or REX2.B4 are generally ignored, except when the register being
addressed is a control or debug register. [...] The exception is that
REX2.R4 and REX2.R3 [*sic*] are not ignored when the R register
identifier addresses a control or debug register. Furthermore, if any
attempt is made to access a non-existent control register (CR*) or debug
register (DR*) using the REX2 prefix and one of the following
instructions:
“MOV CR*, r64”, “MOV r64, CR*”, “MOV DR*, r64”, “MOV r64, DR*”. #UD is
raised.

The invalid encodings are 64-bit only because `0xd5` is a valid
instruction in 32-bit mode.

show more ...

[X86] Support promoted ENQCMD, KEYLOCKER and USERMSR (#77293)

R16-R31 was added into GPRs in
https://github.com/llvm/llvm-project/pull/70958,
This patch supports the promoted ENQCMD, KEYLOCKER and

[X86] Support promoted ENQCMD, KEYLOCKER and USERMSR (#77293)

R16-R31 was added into GPRs in
https://github.com/llvm/llvm-project/pull/70958,
This patch supports the promoted ENQCMD, KEYLOCKER and USER-MSR
instructions in EVEX space.

RFC:
https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4

show more ...

[X86][MC] Support Enc/Dec for NF BMI instructions (#76709)

Promoted BMI instructions were supported in #73899

[X86][MC] Support encoding/decoding for APX variant ADD/SUB/ADC/SBB/OR/XOR/NEG/NOT instructions (#76319)

Four variants: promoted legacy, ND (new data destination), NF (no flags
update) and NF_ND (N

[X86][MC] Support encoding/decoding for APX variant ADD/SUB/ADC/SBB/OR/XOR/NEG/NOT instructions (#76319)

Four variants: promoted legacy, ND (new data destination), NF (no flags
update) and NF_ND (NF + ND).

The syntax of NF instructions is aligned with GNU binutils.
https://sourceware.org/pipermail/binutils/2023-September/129545.html

show more ...

[X86][MC] Support Enc/Dec for EGPR for promoted MOVDIR instruction (#74713)

R16-R31 was added into GPRs in
https://github.com/llvm/llvm-project/pull/70958,
This patch supports the encoding/decodin

[X86][MC] Support Enc/Dec for EGPR for promoted MOVDIR instruction (#74713)

R16-R31 was added into GPRs in
https://github.com/llvm/llvm-project/pull/70958,
This patch supports the encoding/decoding for promoted MOVDIR
instruction in EVEX space.

RFC:
https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4

show more ...

[X86][MC] Support encoding/decoding for PUSH2[P]/POP2[P] (#73233)

PUSH2 and POP2 are two new instructions for (respectively)
pushing/popping 2 GPRs at a time to/from
the stack. The opcodes of PUSH

[X86][MC] Support encoding/decoding for PUSH2[P]/POP2[P] (#73233)

PUSH2 and POP2 are two new instructions for (respectively)
pushing/popping 2 GPRs at a time to/from
the stack. The opcodes of PUSH2 and POP2 are those of “PUSH r/m” and
“POP r/m” from legacy map 0, but we
require ModRM.Mod = 3 in order to disallow memory operand.

The 1-bit Push-Pop Acceleration hint described in #73092 applies to
PUSH2/POP2 too, then we have PUSH2P/POP2P.

For AT&T syntax, PUSH2[P] pushes the registers from right to left onto
the stack. POP2[P] pops the stack to registers from right to left. Intel
syntax has the opposite order - from left to right.

The assembly syntax is aligned with GCC & binutils
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637718.html

show more ...

[X86][MC] Support encoding/decoding for PUSHP/POPP (#73092)

A PUSH and its corresponding POP may be marked with a 1-bit Push-Pop Acceleration (PPX)
hint to indicate that the POP reads the value wri

[X86][MC] Support encoding/decoding for PUSHP/POPP (#73092)

A PUSH and its corresponding POP may be marked with a 1-bit Push-Pop Acceleration (PPX)
hint to indicate that the POP reads the value written by the PUSH from the stack. The PPX hint
is encoded by setting REX2.W = 1 and is applicable only to PUSH with opcode 0x50+rd and POP
with opcode 0x58+rd in the legacy space. It is not applicable to any other variants of PUSH and POP.

show more ...

[X86][MC] Support encoding/decoding for JMPABS (#72835)

JMPABS is a 64-bit only ISA extension, and acts as a near-direct branch
with an absolute target. The 64-bit immediate operand is treated an a

[X86][MC] Support encoding/decoding for JMPABS (#72835)

JMPABS is a 64-bit only ISA extension, and acts as a near-direct branch
with an absolute target. The 64-bit immediate operand is treated an as
absolute effective address, which is subject to canonicality checks. It
is in legacy map 0 and requires REX2 prefix with `REX2.M0=0` and
`REX2.W=0`. All other REX2 payload bits are ignored.

blog: https://kanrobert.github.io/rfc/All-about-APX-JMPABS/

This patch
1. Extends `ExplicitVEXPrefix` to `ExplicitOpPrefix` for instrcutions
requires explicit `REX2` or `EVEX`
2. Adds `ATTR_REX2` and `IC_64BIT_REX2` to put `JMPABS` , `MOV EAX,
moffs32` in different tables to avoid opcode conflict

NOTE:
1. `ExplicitREX2Prefix` can be reused by the following PUSHP/POPP
instructions.
2. `ExplicitEVEXPrefix` will be used by the instructions promoted to
EVEX space for EGPR.

show more ...

[X86][MC] Support decoding of EGPR for APX (#72102)

https://github.com/llvm/llvm-project/pull/70958 adds registers R16-R31
(EGPR), this patch


1. Supports decoding of EGPR for instruction w/ RE

[X86][MC] Support decoding of EGPR for APX (#72102)

https://github.com/llvm/llvm-project/pull/70958 adds registers R16-R31
(EGPR), this patch


1. Supports decoding of EGPR for instruction w/ REX2 prefix
2. Supports decoding of EGPR for instruction w/ EVEX prefix

For simplicity's sake, we
1. Simulate the REX prefix w/ the 1st payload of REX2
2. Simulate the REX2 prefix w/ the 2nd and 3rd payloads of EVEX

RFC:

https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4

Explanations for some changes:
1. invalid-EVEX-R2.txt is deleted b/c `0x62 0xe1 0xff 0x08 0x79 0xc0` is
valid and decoded to `vcvtsd2usi %xmm0, %r16` now.
2. One line in x86-64-err.txt is removed b/c APX relaxes the limitation
of the 1st and 2nd payloads of EVEX prefix, so the error message changes

show more ...

[X86] Add USER_MSR instructions. (#68944)

For more details about this instruction, please refer to the latest ISE
document:
https://www.intel.com/content/www/us/en/develop/download/intel-architect

[X86] Add USER_MSR instructions. (#68944)

For more details about this instruction, please refer to the latest ISE
document:
https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

show more ...

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces suppo

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.

show more ...

[X86][Disassembler][NFCI] Read bytes with support::endian::read

[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.

[X86][Disassembler] Fix displacement operand size for symbolizer

On 64-bit X86, 0x66 operand-size override prefix will change the size of
the instruction operand, e.g. from 32 bits to 16 bits, but i

[X86][Disassembler] Fix displacement operand size for symbolizer

On 64-bit X86, 0x66 operand-size override prefix will change the size of
the instruction operand, e.g. from 32 bits to 16 bits, but it will not
modify the size of the displacement operand used for memory addressing,
which will always be 32 bits.

Reviewed By: skan, rafauler

Differential Revision: https://reviews.llvm.org/D126726

show more ...

[MCDisassembler] Disambiguate Size parameter in tryAddingSymbolicOperand()

MCSymbolizer::tryAddingSymbolicOperand() overloaded the Size parameter
to specify either the instruction size or the operan

[MCDisassembler] Disambiguate Size parameter in tryAddingSymbolicOperand()

MCSymbolizer::tryAddingSymbolicOperand() overloaded the Size parameter
to specify either the instruction size or the operand size depending on
the architecture. However, for proper symbolic disassembly on X86, we
need to know both sizes, as an instruction can have two operands, and
the instruction size cannot be reliably calculated based on the operand
offset and its size. Hence, split Size into OpSize and InstSize.

For X86, the new interface allows to fix a couple of issues:
* Correctly adjust the value of PC-relative operands.
* Set operand size to zero when the operand is specified implicitly.

Differential Revision: https://reviews.llvm.org/D126101

show more ...

[X86][NFCI] Remove redundant functions

Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D121731