| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338293
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Bringing some come duplicated in the AT&T and the Intel printers
into a common parent class.
Reviewers: craig.topper
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D47682
llvm-svn: 334005
|
| |
|
|
|
|
|
|
| |
Previously for instructions like fxsave we would print "opaque ptr" as part of the memory operand. Now we print nothing.
We also no longer accept "opaque ptr" in the parser. We still accept any size to be specified for these instructions, but we may want to consider only parsing when no explicit size is specified. This what gas does.
llvm-svn: 331243
|
| |
|
|
|
|
| |
This matches objdump.
llvm-svn: 330922
|
| |
|
|
|
|
|
|
|
|
| |
'data32' in 16-bit mode. Hack the asm parser to convert 'data32' to 'data16' in 16-bit mode.
Improve the error messages to match GNU assembler.
This also allows us to remove the hack from the disassembler table building.
llvm-svn: 330531
|
| |
|
|
|
|
|
|
| |
EmitAnyX86InstComments. Just always use the function from the ATTPrinter. NFC
The IntelPrinter and the ATTPrinter produce the same strings for the same input. We already use the ATTPrinter explicitly in several other places.
llvm-svn: 328762
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET).
IBT instruments ENDBR instructions used to specify valid targets of indirect call / jmp.
The `nocf_check` attribute has two roles in the context of X86 IBT technology:
1. Appertains to a function - do not add ENDBR instruction at the beginning of the function.
2. Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction.
This patch implements `nocf_check` context for Indirect Branch Tracking.
It also auto generates `nocf_check` prefixes before indirect branchs to jump tables that are guarded by range checks.
Differential Revision: https://reviews.llvm.org/D41879
llvm-svn: 327767
|
| |
|
|
|
|
|
|
| |
MVT belongs to the CodeGen layer, but ShuffleDecode is used by the X86 InstPrinter which is part of the MC layer. This only worked because MVT is completely implemented in a header file with no other library dependencies.
Differential Revision: https://reviews.llvm.org/D44353
llvm-svn: 327292
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are 3 different operand orders for FMA instructions so figuring out the exact operation being performed requires a lot of thought.
This patch adds a comment to the end of the assembly line to print the exact operation.
I think I've got all the instructions in here except the ones with builtin rounding.
I didn't update all tests, but I assume we can get them as we regenerate tests in the future.
Reviewers: spatel, v_klochkov, RKSimon
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44345
llvm-svn: 327225
|
| |
|
|
|
|
| |
The equivalent SSE and VEX instruction are already there.
llvm-svn: 327205
|
| |
|
|
|
|
|
|
|
|
| |
X86InstComments.h.
X86InstComments.h is used by tools that only have the MC layer. We shouldn't be importing a file from CodeGen into this.
X86InstrInfo.h isn't a great place, but I couldn't find a better one.
llvm-svn: 327202
|
| |
|
|
|
|
|
|
| |
determine whether the instruction is masked.
This should have been NFC, but it looks like we were missing PUNPCKLHQDQ/PUNPCKLQDQ instructions in there.
llvm-svn: 327200
|
| |
|
|
|
|
|
|
| |
parsed from the asm parser.
The asm parser puts the lock prefix in the MCInst flags so we need to check that in addition to TSFlags. This matches what the ATT printer does.
llvm-svn: 323469
|
| |
|
|
| |
llvm-svn: 323468
|
| |
|
|
| |
llvm-svn: 320693
|
| |
|
|
|
|
| |
This makes things consistent with our normal instruction naming.
llvm-svn: 320316
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39546
llvm-svn: 317330
|
| |
|
|
|
|
| |
PR7709, PR17697, PR19251, PR32809 and PR21640. There could be other bugs closed by this patch.
llvm-svn: 315899
|
| |
|
|
|
|
| |
We can just write directly to the raw_ostream.
llvm-svn: 315399
|
| |
|
|
| |
llvm-svn: 315395
|
| |
|
|
|
|
|
|
|
| |
x86-asm-syntax=intel (PR34617).
Fix for incorrect code generation when x86-asm-syntax=intel.
Differential Revision: https://reviews.llvm.org/D37945
llvm-svn: 314140
|
| |
|
|
|
|
| |
The existing decodes only worked for v16i8 vectors, this adds support for any 128-bit vector
llvm-svn: 307095
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
|
| |
|
|
| |
llvm-svn: 304332
|
| |
|
|
|
|
|
|
| |
latencies/throughputs.
The details are here: https://reviews.llvm.org/D30941
llvm-svn: 300311
|
| |
|
|
|
|
| |
This is preparation to reduce MCExpr.h dependencies.(vlsj-clangbuild)[622]
llvm-svn: 294246
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch fixes bugzilla 31576 (https://llvm.org/bugs/show_bug.cgi?id=31576).
"data32" instruction prefix was not defined in the llvm.
An exception had to be added to the X86 tablegen and AsmPrinter because both "data16" and "data32" are encoded to 0x66 (but in different modes).
Differential Revision: https://reviews.llvm.org/D28468
llvm-svn: 292352
|
| |
|
|
|
|
|
|
|
|
|
|
| |
size by encoding EVEX AVX-512 instructions using the shorter VEX encoding when possible.
There are cases of AVX-512 instructions that have two possible encodings. This is the case with instructions that use vector registers with low indexes of 0 - 15 and do not use the zmm registers or the mask k registers.
The EVEX encoding prefix requires 4 bytes whereas the VEX prefix can take only up to 3 bytes. Consequently, using the VEX encoding for these instructions results in a code size reduction of ~2 bytes even though it is compiled with the AVX-512 features enabled.
Reviewers: Craig Topper, Zvi Rackoover, Elena Demikhovsky
Differential Revision: https://reviews.llvm.org/D27901
llvm-svn: 290663
|
| |
|
|
|
|
|
|
|
|
| |
size as i128mem. Change all uses to the use the i64mem version.
I'm sure this caused the load size to misprint in Intel syntax output. We were also inconsistent about which patterns used which instruction between VEX and EVEX.
There are two different reg/reg versions of movq, one from a GPR and one from the lower 64-bits of an XMM register. This changes the loading folding table to use the single i64mem memory form for folding both cases. But we need to use TB_NO_REVERSE to prevent a duplicate entry in the unfolding table.
llvm-svn: 287622
|
| |
|
|
|
|
| |
other instructions. NFC
llvm-svn: 287519
|
| |
|
|
| |
llvm-svn: 284915
|
| |
|
|
|
|
| |
shuffle decode comments
llvm-svn: 284821
|
| |
|
|
| |
llvm-svn: 284688
|
| |
|
|
| |
llvm-svn: 284305
|
| |
|
|
|
|
| |
Follow up to r278902. I had missed "fall through", with a space.
llvm-svn: 278970
|
| |
|
|
| |
llvm-svn: 275939
|
| |
|
|
| |
llvm-svn: 275400
|
| |
|
|
| |
llvm-svn: 274469
|
| |
|
|
| |
llvm-svn: 274468
|
| |
|
|
| |
llvm-svn: 274467
|
| |
|
|
|
|
| |
comments
llvm-svn: 274466
|
| |
|
|
| |
llvm-svn: 274464
|
| |
|
|
| |
llvm-svn: 274462
|
| |
|
|
| |
llvm-svn: 274461
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds support for including the avx512 mask register information in the mask/maskz versions of shuffle instruction comments.
This initial version just adds support for MOVDDUP/MOVSHDUP/MOVSLDUP to reduce the mass of test regenerations, other shuffle instructions can be added in due course.
Differential Revision: http://reviews.llvm.org/D21953
llvm-svn: 274459
|
| |
|
|
|
|
|
|
| |
generation
Now matches other shuffles
llvm-svn: 272464
|
| |
|
|
| |
llvm-svn: 272371
|
| |
|
|
|
|
| |
shuffles. Previously we were printing the mask operands as the register names.
llvm-svn: 272367
|
| |
|
|
| |
llvm-svn: 272319
|
| |
|
|
|
|
| |
masks. There are still more bugs here with UNPCK and PALIGN for sure. But these were the easiest ones to fix.
llvm-svn: 272252
|