| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 260500
|
|
|
|
| |
llvm-svn: 260499
|
|
|
|
|
|
|
|
|
| |
Currently you can't specify node properties like commutativity on
a PatFrag. If you want to create a PatFrag on a commutative node
with a hasOneUse predicate, this enables you to specify that the
PatFrag is also commutable.
llvm-svn: 260404
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes it possible to specify some operands as optional to the AsmMatcher.
Setting this field to true will prevent the AsmMatcher from emitting
'too few operands' errors when there are missing optional operands.
Reviewers: olista01, ab
Subscribers: nhaustov, arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15755
llvm-svn: 259913
|
|
|
|
|
|
|
|
| |
CodeGenTarget.cpp to avoid the ordering dependence. NFCI.
Differential Revision: http://reviews.llvm.org/D16826
llvm-svn: 259726
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds a reserve call to an expensive function
(`llvm::LoadIntrinsics`), and may fix a few other low hanging
performance fruit (I've put them in comments for now, so we can
discuss).
**Motivation:**
As I'm sure other developers do, when I build LLVM, I build the entire
project with the same config (`Debug`, `MinSizeRel`, `Release`, or
`RelWithDebInfo`). However, the `Debug` config also builds llvm-tblgen
in `Debug` mode. Later build steps that run llvm-tblgen then can
actually be the slowest steps in the entire build. Nobody likes slow
builds.
Reviewers: rnk, dblaikie
Differential Revision: http://reviews.llvm.org/D16832
Patch by Alexander G. Riccio
llvm-svn: 259683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds a new attribute which targets can set in TableGen which causes a function to be generated which matches register alternative names. This is very similar to `ShouldEmitMatchRegisterName`, except it works on alt names.
This patch is currently used by the out of tree part of the AVR backend. It reduces code duplication greatly, and has the effect that you do not need to hardcode altname to register mappings in C++.
It will not work on targets which have registers which share the same aliases.
Reviewers: stoklund, arsenm, dsanders, hfinkel, vkalintiris
Subscribers: hfinkel, dylanmckay, llvm-commits
Differential Revision: http://reviews.llvm.org/D16312
llvm-svn: 259636
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D16793
llvm-svn: 259539
|
|
|
|
|
|
| |
of accidentally copying to a vector.
llvm-svn: 259336
|
|
|
|
| |
llvm-svn: 259314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This brings the compile time of Function.cpp from ~40s down to ~4s for
me locally. It also shaves off about 400KB of object file size in a
release+asserts build.
I also realized that the AMDGPU backend does not have any GCC builtin
names to match, so the extra lookup was a no-op. I removed it to silence
a zero-length string table array warning. There should be no functional
change here.
This change really ends the story of PR11951.
llvm-svn: 258897
|
|
|
|
|
|
|
|
|
| |
The AMDGPU backend was the last user of the old StringMatcher
recognition code. Move it over to the new lookupLLVMIntrinsicName
funciton, which is now improved to handle all of the interesting edge
cases exposed by AMDGPU intrinsic names.
llvm-svn: 258875
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
llvm-svn: 258861
|
|
|
|
|
|
|
|
| |
other minor fixes.
Differential revision: reviews.llvm.org/D16568
llvm-svn: 258831
|
|
|
|
|
|
|
|
|
|
|
|
| |
Step one towards using a simple binary search to lookup intrinsic IDs
instead of our crazy table generated switch+memcmp+startswith code that
makes Function.cpp take about a minute to compile. See PR24785 and
PR11951 for why we should do this.
The X86 backend contains tables that need to be sorted on intrinsic ID,
so reorder those.
llvm-svn: 258757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fix for https://llvm.org/bugs/show_bug.cgi?id=22796.
The previous implementation of ClassInfo::operator< allowed cycles of classes
such that x < y < z < x, meaning that a list of them cannot be correctly
sorted, and the sort order could differ with different standard libraries.
The original implementation sorted classes by ValueName if they were otherwise
equal. This isn't strictly necessary, but some backends seem to accidentally
rely on it. If I reverse this comparison I get 8 test failures spread across
the AArch64, Mips and X86 backends, so I have left it in until those backends
can be fixed.
There was one case in the X86 backend where the observable behaviour of the
assembler is changed by this patch. This was because some of the memory asm
operands were not marked as children of X86MemAsmOperand.
Differential Revision: http://reviews.llvm.org/D16141
llvm-svn: 258677
|
|
|
|
|
|
|
|
| |
mapping from instruction to unique command, instead store a list of which instructions each unique command corresponds to.
This simplifies the complexity of the code that tries to find further operands to merge into the unique command.
llvm-svn: 258656
|
|
|
|
|
|
| |
consumes it later. NFC
llvm-svn: 258490
|
|
|
|
|
|
| |
size. NFC
llvm-svn: 258489
|
|
|
|
|
|
| |
anything. NFC
llvm-svn: 258488
|
|
|
|
|
|
|
|
|
|
|
| |
The selection process being split into separate passes, we need generic opcodes
to translate the LLVM IR to target independent code.
This patch adds an opcode for addition: G_ADD.
Differential Revision: http://reviews.llvm.org/D15472
llvm-svn: 258333
|
|
|
|
|
|
| |
vector. This removes the state needed to manage the extra vector thus reducing the size of the Record class. NFC
llvm-svn: 258065
|
|
|
|
| |
llvm-svn: 258020
|
|
|
|
|
|
| |
to make an iterator_range when we already have a function that returns an ArrayRef. NFC
llvm-svn: 258019
|
|
|
|
|
|
| |
getInstructionsByEnumValue(). NFC
llvm-svn: 258018
|
|
|
|
| |
llvm-svn: 258017
|
|
|
|
|
|
| |
passed to a function that takes a StringRef anyway. NFC
llvm-svn: 258007
|
|
|
|
|
|
|
|
| |
AsmWriterInst map. NFC
Adds the corresponding CodeGenInstruction number to each AsmWriterInst. Then write all the operand uniqueing loops using the AsmWriterInst array and indices. Then use the CodeGenInstruction index to fill out the OpCodeInfo array.
llvm-svn: 258005
|
|
|
|
| |
llvm-svn: 258004
|
|
|
|
|
|
| |
the flag in every AsmWriterOperand. NFC
llvm-svn: 257743
|
|
|
|
|
|
| |
the AsmMatcher uses when it overflows the 64-bit tables. No in tree targets use this code, but I tested it with an temporarily reduced table width.
llvm-svn: 257583
|
|
|
|
|
|
| |
64-bits for cleanliness. NFC
llvm-svn: 257582
|
|
|
|
| |
llvm-svn: 257581
|
|
|
|
| |
llvm-svn: 257580
|
|
|
|
|
|
| |
simple functions. NFC
llvm-svn: 257579
|
|
|
|
|
|
|
|
| |
allows x86 to use 56 total bits made up of a 32-bit, 16-bit, and 8-bit table. Previously we were using 64 total bits.
This saves 14K from the x86 table size. And saves space on other targets as well.
llvm-svn: 257315
|
|
|
|
|
|
| |
to prevent ending an array with a comma. But that's perfectly legal and not something we need to prevent. NFC
llvm-svn: 257314
|
|
|
|
| |
llvm-svn: 257308
|
|
|
|
|
|
| |
index name as an outer loop. NFC
llvm-svn: 257156
|
|
|
|
|
|
| |
into a vector instead of copying. NFC
llvm-svn: 257155
|
|
|
|
|
|
| |
in the support library will be deleted.
llvm-svn: 256732
|
|
|
|
|
|
| |
empty before printing. The loop can be made to print the same thing if the loop is empty. NFC
llvm-svn: 256703
|
|
|
|
|
|
| |
comparison for readability. NFC
llvm-svn: 256699
|
|
|
|
| |
llvm-svn: 256698
|
|
|
|
|
|
| |
still emitted a closing curly brace.
llvm-svn: 256697
|
|
|
|
| |
llvm-svn: 256696
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r252440 to the Hexagon target.
This restores the previous behavior of not including the mnemonic in the classes table for every target that starts instruction lines with the mnemonic. Not only did the table size increase by 1 entry, but the class enum increased in size which caused every class in the array to increase in size. It also grew the size of the function that parsers tokens into classes by a substantial amount.
This adds a new HasMnemonicFirst flag to all AsmParsers. It's set to 1 by default and Hexagon target overrides it to 0.
For the X86 target alone this recovers 324KB of size on the llvm-mc executable.
I believe the current state is still a bad design choice for the Hexagon target as it causes most of the parsing to do a linear search through the entire match table to comparing operands against every instruction until it finds one that works. At least for the other targets we do a binary search based on mnemonic over which to do the linear scan.
llvm-svn: 256669
|
|
|
|
| |
llvm-svn: 256668
|
|
|
|
|
|
| |
of trying to search characters around the token. No functional change intended. Verified for in-tree targets.
llvm-svn: 256660
|
|
|
|
|
|
| |
outputting to a raw_ostream. NFC
llvm-svn: 256628
|