summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Adapt more places to getValueAsString now returning a StringRef ↵Craig Topper2017-05-311-8/+7
| | | | | | instead of a std::string. llvm-svn: 304347
* TableGen: Use StringInit instead of std::string for DagInit arg namesMatthias Braun2016-12-051-3/+5
| | | | llvm-svn: 288644
* TableGen: Use StringRef instead of const std::string& in return vals.Matthias Braun2016-12-041-3/+3
| | | | | | | This will allow to switch to a different string storage in an upcoming commit. llvm-svn: 288612
* Fix some Clang-tidy and Include What You Use warnings; other minor fixes (NFC).Eugene Zelenko2016-11-301-47/+58
| | | | | | This preparation to remove SetVector.h dependency on SmallSet.h. llvm-svn: 288256
* Switch SmallSetVector to use DenseSet when it overflows its inline space.Justin Lebar2016-10-211-5/+6
| | | | | | | | | | | | | | | | | | | | Summary: SetVector already used DenseSet, but SmallSetVector used std::set. This leads to surprising performance differences. Moreover, it means that the set of key types accepted by SetVector and SmallSetVector are quite different! In order to make this change, we had to convert some callsites that used SmallSetVector<std::string, N> to use SmallSetVector<CachedHashString, N> instead. Reviewers: timshen Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25648 llvm-svn: 284887
* Use StringRef in TableGen (NFC)Mehdi Amini2016-10-041-1/+1
| | | | llvm-svn: 283273
* Use the range variant of find/find_if instead of unpacking begin/endDavid Majnemer2016-08-121-6/+2
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278469
* TableGen: Allow custom register operand decoder methodMatt Arsenault2016-07-181-25/+33
| | | | | | | | | | | | | | | | | | This is for a situation where the encoding for a register may be different depending on the specific operand. For some instructions, we want to apply additional restrictions beyond the encoding's constraints. In AMDGPU some operands are VSrc_32, using the VS_32 pseudo register class which accept VGPRs, SGPRs, or immediates in the encoding. Some specific instructions with the same encoding operand do not want to allow immediates or SGPRs, but the encoding format is different in this case than a regular VGPR_32 operand. This allows specifying the encoding should be treated the same without introducing yet another dummy register class. llvm-svn: 275929
* [TableGen] Remove dead code. NFCI.Davide Italiano2016-07-041-28/+0
| | | | llvm-svn: 274515
* Apply most suggestions of clang-tidy's performance-unnecessary-value-paramBenjamin Kramer2016-06-081-6/+4
| | | | | | | Avoids unnecessary copies. All changes audited & pass tests with asan. No functional change intended. llvm-svn: 272190
* Apply clang-tidy's misc-move-constructor-init throughout LLVM.Benjamin Kramer2016-05-271-11/+11
| | | | | | No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270997
* No need to use utostr/utohexstr when writing into a raw_ostream. NFCCraig Topper2016-01-311-24/+30
| | | | llvm-svn: 259314
* [TableGen] Return ArrayRef instead of a std::vector reference from ↵Craig Topper2016-01-171-10/+10
| | | | | | getInstructionsByEnumValue(). NFC llvm-svn: 258018
* Default SetVector to use a DenseSet.Rafael Espindola2015-11-181-2/+2
| | | | | | | | | | | | | | | We use to have an odd difference among MapVector and SetVector. The map used a DenseMop, but the set used a SmallSet, which in turn uses a std::set. I have changed SetVector to use a DenseSet. If you were depending on the old behaviour you can pass an explicit set type or use SmallSetVector. The common cases for needing to do it are: * Optimizing for small sets. * Sets for types not supported by DenseSet. llvm-svn: 253439
* Fix three typos in comments; "easilly" -> "easily".Nick Lewycky2015-08-181-2/+2
| | | | llvm-svn: 245379
* Remove and forbid raw_svector_ostream::flush() calls.Yaron Keren2015-08-131-4/+0
| | | | | | | | | | After r244870 flush() will only compare two null pointers and return, doing nothing but wasting run time. The call is not required any more as the stream and its SmallString are always in sync. Thanks to David Blaikie for reviewing. llvm-svn: 244928
* Remove raw_svector_ostream::resync and users. It's no-op after r244870.Yaron Keren2015-08-131-2/+0
| | | | llvm-svn: 244888
* Explicitly clear the MI operand list when getInstruction() is called. Call ↵Cameron Esfahani2015-08-111-0/+1
| | | | | | | | | | | | | | MI.clear() within MCD::OPC_Decode case and inside of translateInstruction() for the X86 target. Remove now unnecessary MI.clear() from ARMDisassembler. Summary: Explicitly clear the MI operand list when getInstruction() is called. Reviewers: hfinkel, t.p.northover, hvarga, kparzysz, jyknight, qcolombet, uweigand Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11665 llvm-svn: 244557
* [TableGen] Improve decoding options for non-orthogonal instructionsPetr Pavlu2015-07-151-31/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When FixedLenDecoder matches an input bitpattern of form [01]+ with an instruction bitpattern of form [01?]+ (where 0/1 are static bits and ? are mixed/variable bits) it passes the input bitpattern to a specific instruction decoder method which then makes a final decision whether the bitpattern is a valid instruction or not. This means the decoder must handle all possible values of the variable bits which sometimes leads to opcode rewrites in the decoder method when the instructions are not fully orthogonal. The patch provides a way for the decoder method to say that when it returns Fail it does not necessarily mean the bitpattern is invalid, but rather that the bitpattern is definitely not an instruction that is recognized by the decoder method. The decoder can then try to match the input bitpattern with other possible instruction bitpatterns. For example, this allows to solve a situation on AArch64 where the `MSR (immediate)` instruction has form: 1101 0101 0000 0??? 0100 ???? ???1 1111 but not all values of the ? bits are allowed. The rejected values should be handled by the `extended MSR (register)` instruction: 1101 0101 000? ???? ???? ???? ???? ???? The decoder will first try to decode an input bitpattern that matches both bitpatterns as `MSR (immediate)` but currently this puts the decoder method of `MSR (immediate)` into a situation when it must be able to decode all possible values of the ? bits, i.e. it would need to rewrite the instruction to `MSR (register)` when it is not `MSR (immediate)`. The patch allows to specify that the decoder method cannot determine if the instruction is valid for all variable values. The decoder method can simply return Fail when it knows it is definitely not `MSR (immediate)`. The decoder will then backtrack the decoding and find that it can match the input bitpattern with the more generic `MSR (register)` bitpattern too. Differential Revision: http://reviews.llvm.org/D7174 llvm-svn: 242274
* Fix comment typoPetr Pavlu2015-07-141-1/+1
| | | | | | Test commit access. llvm-svn: 242128
* [TableGen] Rename ListInit::getSize to just 'size' to be more consistent.Craig Topper2015-06-021-3/+3
| | | | llvm-svn: 238806
* Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer2015-05-291-6/+6
| | | | | | | | | | | | | | | | | | | | 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
* Use std::bitset for SubtargetFeatures.Michael Kuperstein2015-05-261-5/+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-1/+1
| | | | | | MCOperand::Create*() methods renamed to MCOperand::create*(). llvm-svn: 237275
* Reverting r237234, "Use std::bitset for SubtargetFeatures"Michael Kuperstein2015-05-131-5/+5
| | | | | | | 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-5/+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
* [TableGen] Prevent invalid code generation when emitting AssemblerPredicate ↵Toma Tabacu2015-04-071-1/+3
| | | | | | | | | | | | | | | | | | | conditions. Summary: The loop which emits AssemblerPredicate conditions also links them together by emitting a '&&'. If the 1st predicate is not an AssemblerPredicate, while the 2nd one is, nothing gets emitted for the 1st one, but we still emit the '&&' because of the 2nd predicate. This generated code looks like "( && Cond2)" and is invalid. Reviewers: dsanders Reviewed By: dsanders Subscribers: dsanders, llvm-commits Differential Revision: http://reviews.llvm.org/D8294 llvm-svn: 234312
* Revert "Use std::bitset for SubtargetFeatures"Michael Kuperstein2015-03-241-5/+5
| | | | | | | | 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-5/+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
* Remove many superfluous SmallString::str() calls.Yaron Keren2015-03-181-1/+1
| | | | | | | | | | | | | | | Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
* Reverting r229831 due to multiple ARM/PPC/MIPS build-bot failures.Michael Kuperstein2015-02-191-5/+5
| | | | llvm-svn: 229841
* Use std::bitset for SubtargetFeaturesMichael Kuperstein2015-02-191-5/+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
* Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for ↵Aaron Ballman2015-02-151-2/+2
| | | | | | requiring the macro. NFC; LLVM edition. llvm-svn: 229340
* Replace size method call of containers to empty method where appropriateAlexander Kornienko2015-01-151-3/+3
| | | | | | | | | | | | | | | | 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
* Use range-based for loops.Craig Topper2014-12-131-52/+35
| | | | llvm-svn: 224187
* Reduce code duplication a bit.Craig Topper2014-09-271-16/+10
| | | | llvm-svn: 218563
* Fix TableGen -gen-disassembler output for bit fields with an offset.Craig Topper2014-09-271-1/+5
| | | | | | | | | This fixes bit assignments like this Inst{7-0} = Foo{9-2} Patch by Steve King. llvm-svn: 218560
* Use vector constructor instead of a for loop to initialize entries.Craig Topper2014-09-041-4/+2
| | | | llvm-svn: 217123
* Fix ambiguous call to make_unique and clang-format.Yaron Keren2014-09-031-13/+7
| | | | llvm-svn: 217023
* Recommit "Use unique_ptr to manager FilterChooser ownership."Craig Topper2014-09-031-23/+16
| | | | | | Just using insert of a pair this time instead of emplace. llvm-svn: 217018
* Revert "Use unique_ptr to manager FilterChooser ownership."Craig Topper2014-09-031-15/+24
| | | | | | std::map::emplace isn't working on some of the bots. llvm-svn: 217015
* Use unique_ptr to manager FilterChooser ownership.Craig Topper2014-09-031-24/+15
| | | | llvm-svn: 217014
* Implement move constructor and remove copy constructor for Filter objects in ↵Craig Topper2014-09-031-13/+8
| | | | | | FixedLenDecoderEmitter. Also remove unused copy constructor of FilterChooser. llvm-svn: 217013
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-2/+2
| | | | | | definition below all of the header #include lines, TableGen edition. llvm-svn: 206846
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-7/+7
| | | | | | instead of comparing to nullptr. llvm-svn: 206254
* [TableGen] Optionally forbid overlap between named and positional operandsHal Finkel2014-03-131-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are currently two schemes for mapping instruction operands to instruction-format variables for generating the instruction encoders and decoders for the assembler and disassembler respectively: a) to map by name and b) to map by position. In the long run, we'd like to remove the position-based scheme and use only name-based mapping. Unfortunately, the name-based scheme currently cannot deal with complex operands (those with suboperands), and so we currently must use the position-based scheme for those. On the other hand, the position-based scheme cannot deal with (register) variables that are split into multiple ranges. An upcoming commit to the PowerPC backend (adding VSX support) will require this capability. While we could teach the position-based scheme to handle that, since we'd like to move away from the position-based mapping generally, it seems silly to teach it new tricks now. What makes more sense is to allow for partial transitioning: use the name-based mapping when possible, and only use the position-based scheme when necessary. Now the problem is that mixing the two sensibly was not possible: the position-based mapping would map based on position, but would not skip those variables that were mapped by name. Instead, the two sets of assignments would overlap. However, I cannot currently change the current behavior, because there are some backends that rely on it [I think mistakenly, but I'll send a message to llvmdev about that]. So I've added a new TableGen bit variable: noNamedPositionallyEncodedOperands, that can be used to cause the position-based mapping to skip variables mapped by name. llvm-svn: 203767
* Remove unnecessary include.Craig Topper2014-02-091-1/+0
| | | | llvm-svn: 201041
* Remove some unnecessary code. The conditions it was checking had already ↵Craig Topper2014-02-091-7/+0
| | | | | | been ruled out by the caller. llvm-svn: 201039
* Add support for positionally-encoded operands to FixedLenDecoderEmitterHal Finkel2013-12-191-4/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, the PowerPC instruction definitions make heavy use of the positional operand encoding heuristic to map operands onto bitfield variables in the instruction definitions. Changing this to use name-based mapping is not trivial, however, because additional infrastructure needs to be designed to handle mapping of complex operands (with multiple suboperands) onto multiple bitfield variables. In the mean time, this adds support for positionally encoded operands to FixedLenDecoderEmitter, so that we can generate a disassembler for the PowerPC backend. To prevent an accidental reliance on this feature, and to prevent an undesirable interaction with existing disassemblers, a backend must opt-in to this support by setting the new decodePositionallyEncodedOperands instruction-set bit to true. When enabled, this iterates the variables that contribute to the instruction encoding, just as the encoder does, and emulates the procedure the encoder uses to map "numbered" operands to variables. The bit range for each variable is also determined as the encoder determines them. This map is then consulted during the decoder-generator's loop over operands to decode, allowing the decoder to understand both position-based and name-based operand-to-variable mappings. As noted in the comment on the decodePositionallyEncodedOperands definition, this support should be removed once it is no longer needed. There should be no change to existing disassemblers. llvm-svn: 197691
* Add support for PointerLikeRegClass to FixedLenDecoderEmitterHal Finkel2013-12-191-0/+4
| | | | | | | | This is more prep for adding the PowerPC disassembler. FixedLenDecoderEmitter should recognize PointerLikeRegClass operands as register types, and generate register-like decoding calls instead of treating them like immediates. llvm-svn: 197680
OpenPOWER on IntegriCloud