summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Support little-endian encodings in the FixedLenDecoderEmitterHal Finkel2013-12-171-0/+2
| | | | | | | | | | | | | | | The convention used to specify the PowerPC ISA is that bits are numbered in reverse order (0 is the index of the high bit). To support this "little endian" encoding convention, CodeEmitterGen will reverse the bit numberings prior to generating the encoding tables. In order to generate a disassembler, FixedLenDecoderEmitter needs to do the same. This moves the bit reversal logic out of CodeEmitterGen and into CodeGenTarget (where it can be used by both CodeEmitterGen and FixedLenDecoderEmitter). This is prep work for disassembly support in the PPC backend (which is the only in-tree user of this little-endian encoding support). llvm-svn: 197532
* Remove several unused variables.Rafael Espindola2013-10-011-1/+0
| | | | | | Patch by Alp Toker. llvm-svn: 191757
* Teaching llvm-tblgen to not emit a switch statement when there are no case ↵Aaron Ballman2013-07-151-8/+13
| | | | | | statements. llvm-svn: 186330
* TableGen/FixedLenDecoderEmitter.cpp: Fix a potential mask overflow in ↵NAKAMURA Takumi2012-12-261-1/+1
| | | | | | | | fieldFromInstruction(). Reported by Yang Yongyong, thanks! llvm-svn: 171101
* Sort the #include lines for utils/...Chandler Carruth2012-12-041-4/+3
| | | | | | | I've tried to find main moudle headers where possible, but the TableGen stuff may warrant someone else looking at it. llvm-svn: 169251
* Remove exception handling usage from tblgen.Joerg Sonnenberger2012-10-251-1/+2
| | | | | | | | | | | Most places can use PrintFatalError as the unwinding mechanism was not used for anything other than printing the error. The single exception was CodeGenDAGPatterns.cpp, where intermediate errors during type resolution were ignored to simplify incremental platform development. This use is replaced by an error flag in TreePattern and bailout earlier in various places if it is set. llvm-svn: 166712
* tblgen: Use semantically correct RTTI functions.Sean Silva2012-10-101-2/+2
| | | | | | Also, some minor cleanup. llvm-svn: 165647
* tblgen: Mechanically move dynamic_cast<> to dyn_cast<>.Sean Silva2012-10-101-6/+6
| | | | | | | | | | Some of these dyn_cast<>'s would be better phrased as isa<> or cast<>. That will happen in a future patch. There are also two dyn_cast_or_null<>'s slipped in instead of dyn_cast<>'s, since they were causing crashes with just dyn_cast<>. llvm-svn: 165646
* tblgen: Replace uses of dynamic_cast<XXXRecTy> with dyn_cast<>.Sean Silva2012-10-051-1/+1
| | | | | | | | This is a mechanical change of dynamic_cast<> to dyn_cast<>. A number of these uses are actually more like isa<> or cast<>, and will be changed to the semanticaly appropriate one in a future patch. llvm-svn: 165291
* TableGen: Add initializer.Jim Grosbach2012-09-171-1/+1
| | | | | | | Keep GCC's warnings happy. It can't reason out that the state machine won't ever hit the potentially uninitialized use in OPC_FilterValue. llvm-svn: 164041
* Re-work bit/bits value resolving in tblgenMichael Liao2012-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - This patch is inspired by the failure of the following code snippet which is used to convert enumerable values into encoding bits to improve the readability of td files. class S<int s> { bits<2> V = !if(!eq(s, 8), {0, 0}, !if(!eq(s, 16), {0, 1}, !if(!eq(s, 32), {1, 0}, !if(!eq(s, 64), {1, 1}, {?, ?})))); } Later, PR8330 is found to report not exactly the same bug relevant issue to bit/bits values. - Instead of resolving bit/bits values separately through resolveBitReference(), this patch adds getBit() for all Inits and resolves bit value by resolving plus getting the specified bit. This unifies the resolving of bit with other values and removes redundant logic for resolving bit only. In addition, BitsInit::resolveReferences() is optimized to take advantage of this origanization by resolving VarBitInit's variable reference first and then getting bits from it. - The type interference in '!if' operator is revised to support possible combinations of int and bits/bit in MHS and RHS. - As there may be illegal assignments from integer value to bit, says assign 2 to a bit, but we only check this during instantiation in some cases, e.g. bit V = !if(!eq(x, 17), 0, 2); Verbose diagnostic message is generated when invalid value is resolveed to help locating the error. - PR8330 is fixed as well. llvm-svn: 163360
* Declare some for loop indices inside the for loop statement.Craig Topper2012-08-171-20/+13
| | | | llvm-svn: 162085
* Fix up indentation of outputted decode function for readability.Craig Topper2012-08-171-8/+8
| | | | llvm-svn: 162082
OpenPOWER on IntegriCloud