summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/AsmMatcherEmitter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Use range-based for loops. NFC.Craig Topper2015-06-021-2/+2
| | | | llvm-svn: 238805
* Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer2015-05-291-6/+4
| | | | | | | | | | | | | | | | | | | | If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238602
* [TableGen][AsmMatcherEmitter] Only parse isolated tokens as registers.Ahmed Bougacha2015-05-291-4/+22
| | | | | | | | | | | | | | Fixes PR23455, where, when TableGen generates the matcher from the AsmString, it splits "cmp${cc}ss" into tokens, and the "ss" suffix is recognized as the SS register. I can't think of a situation where that's a feature, not a bug, hence: when a token is "isolated", i.e., it is followed and preceded by separators, it shouldn't be parsed as a register. Differential Revision: http://reviews.llvm.org/D9844 llvm-svn: 238536
* [TableGen][AsmMatcherEmitter] Factor out AsmOperand creation. NFC.Ahmed Bougacha2015-05-291-8/+15
| | | | llvm-svn: 238534
* AsmMatcherEmitter: Add an option to override custom converters for InstAliasTom Stellard2015-05-261-3/+12
| | | | | | | | | | | | | | | | | If there is an InstAlias defined for an instruction that had a custom converter (AsmMatchConverter), then when the alias is matched, the custom converter will be used rather than the converter generated by the InstAlias. This patch adds the UseInstAsmMatchConverter field to the InstAlias class, which allows you to override this behavior and force the converter generated by the InstAlias to be used. This is required for some future improvemnts to the R600 assembler. Differential Revision: http://reviews.llvm.org/D9083 llvm-svn: 238210
* Use std::bitset for SubtargetFeatures.Michael Kuperstein2015-05-261-7/+5
| | | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. The first several times this was committed (e.g. r229831, r233055), it caused several buildbot failures. Apparently the reason for most failures was both clang and gcc's inability to deal with large numbers (> 10K) of bitset constructor calls in tablegen-generated initializers of instruction info tables. This should now be fixed. llvm-svn: 238192
* MC: Modernize MCOperand API naming. NFC.Jim Grosbach2015-05-131-2/+2
| | | | | | MCOperand::Create*() methods renamed to MCOperand::create*(). llvm-svn: 237275
* Reverting r237234, "Use std::bitset for SubtargetFeatures"Michael Kuperstein2015-05-131-5/+7
| | | | | | | The buildbots are still not satisfied. MIPS and ARM are failing (even though at least MIPS was expected to pass). llvm-svn: 237245
* Use std::bitset for SubtargetFeaturesMichael Kuperstein2015-05-131-7/+5
| | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. The first two times this was committed (r229831, r233055), it caused several buildbot failures. At least some of the ARM and MIPS ones were due to gcc/binutils issues, and should now be fixed. llvm-svn: 237234
* Revert "Use std::bitset for SubtargetFeatures"Michael Kuperstein2015-03-241-5/+7
| | | | | | | | This reverts commit r233055. It still causes buildbot failures (gcc running out of memory on several platforms, and a self-host failure on arm), although less than the previous time. llvm-svn: 233068
* Use std::bitset for SubtargetFeaturesMichael Kuperstein2015-03-241-7/+5
| | | | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. The first time this was committed (r229831), it caused several buildbot failures. At least some of the ARM ones were due to gcc/binutils issues, and should now be fixed. Differential Revision: http://reviews.llvm.org/D8542 llvm-svn: 233055
* TableGen: Initialize ErrorInfo to ~0ULL in the MatchInstructionImplTom Stellard2015-03-051-1/+1
| | | | | | | | This is what all the targets check for and is consistent with the initialized value of MissingFeatures, which is sometimes assinged to ErrorInfo. llvm-svn: 231397
* Add a FIXME for PR22796, broken ordering of ClassInfo in TableGenDavid Blaikie2015-03-041-0/+5
| | | | | | As discussed (at length) in code review of r222935, with Duncan. llvm-svn: 231282
* Revert "Remove the explicit SDNodeIterator::operator= in favor of the ↵David Blaikie2015-03-031-2/+0
| | | | | | | | | | | implicit default" Accidentally committed a few more of these cleanup changes than intended. Still breaking these out & tidying them up. This reverts commit r231135. llvm-svn: 231136
* Remove the explicit SDNodeIterator::operator= in favor of the implicit defaultDavid Blaikie2015-03-031-0/+2
| | | | | | | | | | There doesn't seem to be any need to assert that iterator assignment is between iterators over the same node - if you want to reuse an iterator variable to iterate another node, that's perfectly acceptable. Just don't mix comparisons between iterators into disjoint sequences, as usual. llvm-svn: 231135
* Replace std::copy with a back inserter with vector append where feasibleBenjamin Kramer2015-02-281-2/+3
| | | | | | | | | All of the cases were just appending from random access iterators to a vector. Using insert/append can grow the vector to the perfect size directly and moves the growing out of the loop. No intended functionalty change. llvm-svn: 230845
* Reverting r229831 due to multiple ARM/PPC/MIPS build-bot failures.Michael Kuperstein2015-02-191-5/+7
| | | | llvm-svn: 229841
* Use std::bitset for SubtargetFeaturesMichael Kuperstein2015-02-191-7/+5
| | | | | | | | | | | Previously, subtarget features were a bitfield with the underlying type being uint64_t. Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset. No functional change. Differential Revision: http://reviews.llvm.org/D7065 llvm-svn: 229831
* MathExtras: Bring Count(Trailing|Leading)Ones and CountPopulation in line ↵Benjamin Kramer2015-02-121-2/+2
| | | | | | | | with countTrailingZeros Update all callers. llvm-svn: 228930
* Replace size method call of containers to empty method where appropriateAlexander Kornienko2015-01-151-2/+2
| | | | | | | | | | | | | | | | This patch was generated by a clang tidy checker that is being open sourced. The documentation of that checker is the following: /// The emptiness of a container should be checked using the empty method /// instead of the size method. It is not guaranteed that size is a /// constant-time function, and it is generally more efficient and also shows /// clearer intent to use empty. Furthermore some containers may implement the /// empty method but not implement the size method. Using empty whenever /// possible makes it easier to switch to another container in the future. Patch by Gábor Horváth! llvm-svn: 226161
* [TableGen] Add support for negative immediates to AsmMatcherEmitterHal Finkel2015-01-151-0/+2
| | | | | | | | | | | | | | | | This adds support for creating an InstAlias with a negative immediate, i.e.: def NOT : InstAlias<"not $dst, $src", (XORI GR32:$dst, GR32:$src, -1)>; by resolving this problem: RISCVGenAsmMatcher.inc:95:11: error: expected '= constant-expression' or end of enumerator definition CVT_imm_-1, ^^^^^^^^^^ Patch by Jordy Potman, thanks! llvm-svn: 226073
* Fix some formatting in tablegen output.Craig Topper2015-01-031-7/+4
| | | | llvm-svn: 225113
* Replace some 'unreachable' comments with llvm_unreachable.Craig Topper2015-01-031-2/+2
| | | | llvm-svn: 225112
* Use iterators rather than indices to make this forwards-compatible with a ↵David Blaikie2014-12-221-4/+5
| | | | | | change to the underlying container (to std::list) llvm-svn: 224734
* unique_ptrify MatchableInfo(const CodeGenInstAlias *Alias)'s parameterDavid Blaikie2014-12-221-14/+11
| | | | llvm-svn: 224733
* [MC] Reset the MCInst in the matcher function before adding opcode/operands.Ahmed Bougacha2014-12-161-0/+1
| | | | | | | | | | | | | | | | | | On X86, the Intel asm parser tries to match all memory operand sizes when none is explicitly specified. For LEA, which doesn't really have a memory operand (just a pointer one), this results in multiple successful matches, one for each memory size. There's no error because it's same opcode, so really, it's just one match. However, the tablegen'd matcher function adds opcode/operands to the passed MCInst, and this results in multiple duplicated operands. This commit clears the MCInst in the tablegen'd matcher function. We sometimes clear it when the match failed, so there's no expectation of keeping the previous content anyway. Differential Revision: http://reviews.llvm.org/D6670 llvm-svn: 224347
* Simplify ownership of RegClasses by using list<CodeGenRegisterClass> instead ↵David Blaikie2014-12-031-11/+11
| | | | | | | | | | of vector<CodeGenRegisterClass*> This complicates a few algorithms due to not having random access, but not by a huge degree I don't think (open to debate/design discussion/etc). llvm-svn: 223261
* Range-for some stuff related to RegClasses, and comment cases where ↵David Blaikie2014-12-031-2/+1
| | | | | | range-for isn't suitable. llvm-svn: 223260
* Remove indirection of vector<T*> in favor of deque<T>David Blaikie2014-11-291-13/+10
| | | | llvm-svn: 222958
* Revert "Simplify some more ownership using forward_list<T> rather than ↵Duncan P. N. Exon Smith2014-11-281-66/+82
| | | | | | | | | | | | vector<unique_ptr<T>>" This reverts commit r222935 and its follow-up r222938 ("Push unique_ptr a bit further through some APIs and simplify some cleanup"), since it causes bot failures (at least on Darwin): http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/1391/ llvm-svn: 222943
* Reapply "Use std::map<K, V> rather than std::map<K, std::unique_ptr<V>>""David Blaikie2014-11-281-16/+14
| | | | | | | | | Just avoid using std::map::emplace since it's not implemented in libstdc++ 4.7. Reapplies r222937, reverted in r222939. llvm-svn: 222940
* Revert "Use std::map<K, V> rather than std::map<K, std::unique_ptr<V>>"David Blaikie2014-11-281-15/+16
| | | | | | | | | Seems libstdc++ on some buildbots is lacking std::map::emplace, which is weird... reverting while I look into it. This reverts commit r222937. llvm-svn: 222939
* Push unique_ptr a bit further through some APIs and simplify some cleanupDavid Blaikie2014-11-281-18/+13
| | | | llvm-svn: 222938
* Use std::map<K, V> rather than std::map<K, std::unique_ptr<V>>David Blaikie2014-11-281-16/+15
| | | | | | | | | | | Pointers and references to map elements are never invalidated (except on removal, which isn't used here) so there's no need for the indirection unless there's polymorphism at work. A little const correctness had to be fixed, since the indirection allowed some benign const violations. llvm-svn: 222937
* Simplify some more ownership using forward_list<T> rather than ↵David Blaikie2014-11-281-65/+54
| | | | | | vector<unique_ptr<T>> llvm-svn: 222935
* Forgotten formatting from previous commitDavid Blaikie2014-11-281-2/+2
| | | | llvm-svn: 222934
* Simplify ownership by using forward_list<T> rather than vector<unique_ptr<T>>David Blaikie2014-11-281-42/+42
| | | | | | | | Since the elements were not polymorphic, the unique_ptr was only used to avoid pointer invalidation on container resizes - might as well skip the indirection and use a container with suitable invalidation semantics. llvm-svn: 222931
* Fix another memory leak in TableGen AsmMatcher by deleting CodeGenInstAliases.Craig Topper2014-11-281-0/+5
| | | | llvm-svn: 222912
* Use unique_ptr to fix some memory leaks in Tablegen AsmMatcherEmitter.Craig Topper2014-11-281-37/+44
| | | | llvm-svn: 222909
* Use range-based for loops and const-correct a few things.Craig Topper2014-11-281-59/+40
| | | | llvm-svn: 222908
* Remove unncessary check for Int_* and *_Int in AsmMatcherEmitter. These are ↵Craig Topper2014-11-251-7/+0
| | | | | | all marked isCodeGenOnly these days. llvm-svn: 222783
* Use range-based for loops.Craig Topper2014-11-251-126/+87
| | | | llvm-svn: 222782
* MCAsmParserExtension has a copy of the MCAsmParser. Use it.Rafael Espindola2014-11-111-1/+1
| | | | | | Base classes were storing a second copy. llvm-svn: 221667
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-6/+6
| | | | | | needing to mention the size. llvm-svn: 216158
* TableGen: allow use of uint64_t for available features mask.Tim Northover2014-08-181-19/+21
| | | | | | | | | | ARM in particular is getting dangerously close to exceeding 32 bits worth of possible subtarget features. When this happens, various parts of MC start to fail inexplicably as masks get truncated to "unsigned". Mostly just refactoring at present, and there's probably no way to test. llvm-svn: 215887
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-6/+6
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-6/+6
| | | | | | needing to mention the size. llvm-svn: 215868
* AsmMatchers: Use unique_ptr to manage ownership of MCParsedAsmOperandDavid Blaikie2014-06-081-24/+23
| | | | | | | | | | | | I saw at least a memory leak or two from inspection (on probably untested error paths) and r206991, which was the original inspiration for this change. I ran this idea by Jim Grosbach a few weeks ago & he was OK with it. Since it's a basically mechanical patch that seemed sufficient - usual post-commit review, revert, etc, as needed. llvm-svn: 210427
* [asm matcher] Fix incorrect assertion when there are exactly 32 ↵Daniel Sanders2014-05-211-13/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | SubtargetFeatures Summary: The minimal type needs to hold a value of '1ULL << 31' but getMinimalTypeForRange() is called with a value of '1ULL << 32'. This patch will also reduce the size of the matcher table when there are 8 or 16 SubtargetFeatures. Also added a dump of the SubtargetFeatures to the -debug output and corrected getMinimalTypeInRange() to consider 0xffffffffull to be a 32-bit value. The testcase is that no existing code is broken and that LLVM still successfully compiles after adding MIPS64r6 CodeGen support. Reviewers: rafael Reviewed By: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D3787 llvm-svn: 209288
* Clean up language and grammar.Eric Christopher2014-05-201-2/+2
| | | | | | | Based on a patch by jfcaron3@gmail.com! PR19806 llvm-svn: 209216
OpenPOWER on IntegriCloud