We can convert the MCRegister to bool instead. I think this should
allows us to remove MCRegister::operator==(int). All other comparisons
in tree are unsigned.
S.substr(N) is simpler than S.slice(N, StringRef::npos) and
S.slice(N, S.size()). Also, substr is probably better recognizable
than slice thanks to std::string_view::substr.
The following commit bfb7099eeb9b6f62510b1db0cb93a8c3cfa68236 added a
special case for End of Statement that doesn't check if the state
machine is rightfully in a state where ending is valid.
This PR suggest to revert this change to make `EndOfStatement` processed
as any other tokens that are not consumable by the state machine.
Fixes https://github.com/llvm/llvm-project/issues/94446
---------
Co-authored-by: v01dxyz <v01dxyz@v01d.xyz>
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
38 under llvm/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
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`).
Fix the bug where merge-fdata unconditionally outputs boltedcollection
line, regardless of whether input files have it set.
Test Plan:
Added bolt/test/X86/merge-fdata-nobat-mode.test which fails without this
fix.
A displacement is an 8-, 16-, or 32-bit value.
LLVM integrated assembler silently encodes an out-of-range displacement.
GNU assembler checks the displacement and may report a warning or error
(error is for 64-bit addressing, done as part of
https://sourceware.org/PR10636).
```
movq 0x80000000(%rip), %rax
Error: 0x80000000 out of range of signed 32bit displacement
movq -0x080000001(%rax), %rax
Error: 0xffffffff7fffffff out of range of signed 32bit displacement
movl 0x100000001(%eax), %eax
Warning: 0x100000001 shortened to 0x1
```
For 32-bit addressing, GNU assembler gives no diagnostic when the
displacement is within `[-2**32,2**32)`. 16-bit addressing is similar.
```
movl 0xffffffff(%eax), %eax # no diagnostic
movl -0xffffffff(%eax), %eax # no diagnostic
```
Supporting a larger range is probably because wraparound using a large
constant is more reasonable. E.g. Linux kernel arch/x86/kernel/head_32.S
has `leal -__PAGE_OFFSET(%ecx),%esp` where `__PAGE_OFFSET` is
0xc0000000.
This patch implements a similar behavior.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
https://reviews.llvm.org/D151863 (2023-05) removed
`BaseReg = BaseReg ? BaseReg : 1` (introduced in commit
175d0aeef3725ce17032e9ef76e018139f2f52f0 (2013)) and caused a
regression: ensuring a non-zero `BaseReg` was to treat
`static void (*fptr)(); __asm { call fptr }` as non-`AbsMem`
`AsmOperandClass` and generate `call $0`/`callq *fptr(%rip)` instead of
`call ${0:P}`/`callq *fptr`
(The asm template argument modifier `P` is for call targets, while
no modifier is used by other instructions like `mov rax, fptr`)
This patch reinstates the BaseReg-setting statement but places it inside
`if (IsGlobalLV)` for clarify.
The special case is unfortunate, but we also have special case in
similar places (https://reviews.llvm.org/D149920).
Fix: #73033
After #72835, ExplicitVEXPrefix has changed and it is not a bit now, but
in scope ExplicitOpPrefix, so the bitwise op of ExplicitVEXPrefix may
need to update.
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.
This finishes the work of replacing OperandMatchResultTy with
ParseStatus, started in D154101.
As a drive-by change, rename some RegNo variables to just Reg
(a leftover from the days when RegNo had 'unsigned' type).
This patch is to fix the [[ https://github.com/llvm/llvm-project/issues/63045 | issue 63045]].
Look at the following code:
```
int main(int argc, char *argv[]) {
int arr[1000];
__asm movdir64b rax, ZMMWORD PTR [arr]
return 0;
}
```
Compiling this code using `clang -O0 -fasm-blocks bug.c` gives the a linker error.
The problem seems to be in the generated assembly. Following is the out put of `clang -S -O0 -fasm-blocks bug.c`:
```
movq %rsi, -16(%rbp)
#APP
movdir64b arr, %rax
#NO_APP
xorl %eax, %eax
```
The symbol `arr` should be replaced with some address like `-4(%rbp)`.
This makes me believe that issue is not in the linker, but with the ASM parser.
This issue originates with patch [D145893](https://reviews.llvm.org/D145893). And that's why reverting it fixes the issue. More specifically, the function [isMem512_GR64()](ff471dcf76/llvm/lib/Target/X86/AsmParser/X86Operand.h (L404)) within the [llvm/lib/Target/X86/AsmParser/X86Operand.h](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/AsmParser/X86Operand.h) file.
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D151863
.Imm can get lexed as a real, but a real doesn't equal to .Imm, e.g.,
2.5 or .123e+8. We should report error for it rather than silently ignore.
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D151652
1. Share code `optimizeInstFromVEX3ToVEX2` with MCInstLower
2. Move the code of optimization for shift/rotate to a separate file
3. Since the function is shared, a side effect is that more encoding
optimizations are done on the Asmparser side. Considering we already
use reverse-encoding for optimization in AsmParser before this patch,
I believe the change is positive and expected.
This is a reland of D150068 with the fix D150440.
This syntax is confusing and likely invalid. In addition, MASM rejects
it and GAS seems to behave oddly with it. Therefore we shall reject this
syntax for both unconditional `call` and `jmp` instructions, as
discussed in D149579.
Depends on D150047
Differential Revision: https://reviews.llvm.org/D150048
Clang on Windows targets often requires indirect calls through the
import address table (IAT), and also .refptr stubs for MinGW target.
On 32-bit this generates assembly in the form of
`call dword ptr [__imp__func]`, which MC had failed to handle correctly.
64-bit targets are not affected because rip-relative addressing is used.
Reported on: https://github.com/llvm/llvm-project/issues/62010
Depends on D149695, D149920
Differential Revision: https://reviews.llvm.org/D149579
1. Share code `optimizeInstFromVEX3ToVEX2` with MCInstLower
2. Move the code of optimization for shift/rotate to a separate file
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D150068
The AOK_SizeDirective part from 5b37c181291210bedfbb7a6af5d51229f3652ef0
(2014-08) seems unneeded nowadays (the root cause has likely been fixed
elsewhere). The part abuses that `call dword ptr foo` assembles the same way as `call
foo` in Intel syntax, which is going to be fixed (changed) by D149579.
The generated object files for
CodeGen/ms-inline-asm{,-functions,-variables,-static-variable}.c and
CodeGenCXX/ms-inline-asm-fields.cpp are unchanged
(-mno-incremental-linker-compatible) with just this patch. When D149579 is
subsequently applied, the FIXME part of `kptr` in
CodeGen/ms-inline-asm-functions.c will be fixed.
Differential Revision: https://reviews.llvm.org/D149695
```
MCRegister getX86SubSuperRegister*(MCRegister Reg, unsigned Size,
bool High = false);
```
A strange behavior of the functions `getX86SubSuperRegister*` was
introduced by llvm-svn:145579: The returned register may not
match the parameters when a 8-bit high register is required.
And llvm-svn: 175762 refined the code and dropped the comments, then we
knew nothing happened there from the code :-(
These two functions are only called with `Size=8` and `High=true` in two places.
One is in `X86FixupBWInsts.cpp` for liveness of registers and the other is in
`X86AsmPrinter.cpp` for inline asm.
For the first one, we provide an alternative in this patch.
For the second one, the strange behaviour caused a bug that an erorr was not reported for mismatched modifier.
```
void f() {
char x;
asm volatile ("mov %%ah, %h0" :"=r"(x)::"%eax", "%ebx", "%ecx", "%edx", "edi", "esi");
}
```
```
$ gcc -S test.c
error: extended registers have no high halves
```
```
$ clang -S test.c
no error
```
so we fix the bug in this patch.
`getX86SubSuperRegister` is just a wrapper of `getX86SubSuperRegisterOrZero` with a `assert`.
I belive we should remove the latter.
Reviewed By: pengfei
Differential Revision: https://reviews.llvm.org/D142834
