| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
For some targets, there is a circular dependency between InstPrinter and
MCTargetDesc. Merging them together will fix this. For the other targets,
the merging is to maintain consistency so all targets will have the same
structure.
llvm-svn: 360484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes hidden codegen flag -print-schedule effectively reverting the
logic originally committed as r300311
(https://llvm.org/viewvc/llvm-project?view=revision&revision=300311).
Flag -print-schedule was originally introduced by r300311 to address PR32216
(https://bugs.llvm.org/show_bug.cgi?id=32216). That bug was about adding "Better
testing of schedule model instruction latencies/throughputs".
These days, we can use llvm-mca to test scheduling models. So there is no longer
a need for flag -print-schedule in LLVM. The main use case for PR32216 is
now addressed by llvm-mca.
Flag -print-schedule is mainly used for debugging purposes, and it is only
actually used by x86 specific tests. We already have extensive (latency and
throughput) tests under "test/tools/llvm-mca" for X86 processor models. That
means, most (if not all) existing -print-schedule tests for X86 are redundant.
When flag -print-schedule was first added to LLVM, several files had to be
modified; a few APIs gained new arguments (see for example method
MCAsmStreamer::EmitInstruction), and MCSubtargetInfo/TargetSubtargetInfo gained
a couple of getSchedInfoStr() methods.
Method getSchedInfoStr() had to originally work for both MCInst and
MachineInstr. The original implmentation of getSchedInfoStr() introduced a
subtle layering violation (reported as PR37160 and then fixed/worked-around by
r330615).
In retrospect, that new API could have been designed more optimally. We can
always query MCSchedModel to get the latency and throughput. More importantly,
the "sched-info" string should not have been generated by the subtarget.
Note, r317782 fixed an issue where "print-schedule" didn't work very well in the
presence of inline assembly. That commit is also reverted by this change.
Differential Revision: https://reviews.llvm.org/D57244
llvm-svn: 353043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This makes things consistent with our normal instruction naming.
llvm-svn: 320316
|
|
|
|
|
|
| |
We can just write directly to the raw_ostream.
llvm-svn: 315399
|
|
|
|
| |
llvm-svn: 315395
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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: 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
|
|
|
|
|
|
| |
instructions. Then add shuffle decode printing for the EVEX forms which is made easier by having the naming structure more similar to other instructions.
llvm-svn: 272249
|
|
|
|
|
|
| |
PSHUFLW.
llvm-svn: 271628
|
|
|
|
|
|
| |
AVX512VL is enabled. Also add shuffle comment printing for AVX512VL VPERMPD/VPERMQ to keep some tests that now use these instructions instead of the AVX2 ones.
llvm-svn: 270317
|
|
|
|
|
|
| |
Fixed incorrect operands indices used to access src registers
llvm-svn: 269221
|
|
|
|
| |
llvm-svn: 269209
|
|
|
|
|
|
|
|
| |
instructions. NFC
This will make it easier to support the different writemask cases in shuffle comments
llvm-svn: 269174
|
|
|
|
|
|
|
|
| |
shuffle comments
This came up in discussion on D19198
llvm-svn: 268915
|
|
|
|
| |
llvm-svn: 260034
|
|
|
|
| |
llvm-svn: 260007
|
|
|
|
|
|
| |
To allow the helper functions to make use of them.
llvm-svn: 259997
|
|
|
|
|
|
|
|
| |
First step towards being able to decode AVX512 PMOVZX instructions without a massive bloat in the shuffle decode switch statement.
This should also make it easier to decode X86ISD::VZEXT target shuffles in the future.
llvm-svn: 259995
|
|
|
|
| |
llvm-svn: 259496
|
|
|
|
| |
llvm-svn: 259430
|
|
|
|
| |
llvm-svn: 259427
|