summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Reduce scope of variable to silence cppcheck warning. NFCSimon Pilgrim2019-11-091-2/+1
|
* [TableGen] Support encoding per-HwModeJames Molloy2019-09-191-9/+56
| | | | | | | | | | | | | | Much like ValueTypeByHwMode/RegInfoByHwMode, this patch allows targets to modify an instruction's encoding based on HwMode. When the EncodingInfos field is non-empty the Inst and Size fields of the Instruction are ignored and taken from EncodingInfos instead. As part of this promote getHwMode() from TargetSubtargetInfo to MCSubtargetInfo. This is NFC for all existing targets - new code is generated only if targets use EncodingByHwMode. llvm-svn: 372320
* [TableGen] Correct comments for end of namespace. NFCBjorn Pettersson2019-08-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: Update end-of-namespace comments generated by tablegen emitters to fulfill the rules setup by clang-tidy's llvm-namespace-comment checker. Fixed a few end-of-namespace comments in the tablegen source code as well. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: craig.topper, stoklund, dschuff, sbc100, jgravelle-google, aheejin, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66396 llvm-svn: 369865
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-2/+2
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [TableGen] Correct the shift to the proper bit width.Michael Liao2019-08-101-1/+1
| | | | | | - Replace the previous 32-bit shift with 64-bit one matching `OpInit`. llvm-svn: 368513
* [TableGen] Add "InitValue": Handle operands with set bit values in decoder ↵Daniel Sanders2019-08-091-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | methods Summary: The problem: When an operand had bits explicitly set to "1" (as in the InitValue.td test case attached), the decoder was ignoring those bits, and the DecoderMethod was receiving an input where the bits were still zero. The solution: We added an "InitValue" variable that stores the initial value of the operand based on what bits were explicitly initialized to 1 in TableGen code. The generated decoder code then uses that initial value to initialize the "tmp" variable, then calls fieldFromInstruction to read the values for the remaining bits that were left unknown in TableGen. This is mainly useful when there are variations of an instruction that differ based on what bits are set in the operands, since this change makes it possible to access those bits in a DecoderMethod. The DecoderMethod can use those bits to know how to handle the input. Patch by Nicolas Guillemot Reviewers: craig.topper, dsanders, fhahn Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D63741 llvm-svn: 368458
* Re-commit r363744: [tblgen][disasm] Allow multiple encodings to disassemble ↵Daniel Sanders2019-06-181-45/+95
| | | | | | | | | | | | | | to the same instruction It seems macOS lets you have ArrayRef<const X> even though this is apparently forbidden by the language standard (Thanks MSVC++ for the clear error message). Removed the problematic const's to fix this. (It also seems I'm not receiving buildbot emails anymore and I'm trying to find out why. In the mean time I'll be polling lab.llvm.org to hopefully see if/when failures occur) llvm-svn: 363753
* Revert [tblgen][disasm] Allow multiple encodings to disassemble to the same ↵Jordan Rupprecht2019-06-181-98/+48
| | | | | | | | | | instruction This reverts r363744 (git commit 9b2252123d1e79d2b3594097a9d9cc60072b83d9) This breaks many buildbots, e.g. http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/203/steps/build%20stage%201/logs/stdio llvm-svn: 363747
* [tblgen][disasm] Allow multiple encodings to disassemble to the same instructionDaniel Sanders2019-06-181-48/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an AdditionalEncoding class which can be used to define additional encodings for a given instruction. This causes the disassembler to add an additional encoding to its matching tables that map to the specified instruction. Usage: def ADD1 : Instruction { bits<8> Reg; bits<32> Inst; let Size = 4; let Inst{0-7} = Reg; let Inst{8-14} = 0; let Inst{15} = 1; // Continuation bit let Inst{16-31} = 0; ... } def : AdditionalEncoding<ADD1> { bits<8> Reg; bits<16> Inst; // You can also have bits<32> and it will still be a 16-bit encoding let Size = 2; let Inst{0-3} = 0; let Inst{4-7} = Reg; let Inst{8-15} = 0; ... } with those definitions, llvm-mc will successfully disassemble both of these: 0x01 0x00 0x10 0x80 0x00 0x00 to: ADD1 r1 Depends on D52366 Reviewers: bogner, charukcs Reviewed By: bogner Subscribers: nlguillemot, nhaehnle, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D52369 llvm-svn: 363744
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [tblgen][disasm] Emit record names again when decoder conflicts occur.Daniel Sanders2019-01-031-1/+1
| | | | | | And add a test for it. llvm-svn: 350277
* Recommit r349041: [tblgen][disasm] Separate encodings from instructionsDaniel Sanders2018-12-131-37/+51
| | | | | | | Removed const from the ArrayRef<const EncodingAndInst> to avoid the std::vector<const EncodingAndInst> that G++ saw llvm-svn: 349055
* Revert r349041: [tblgen][disasm] Separate encodings from instructionsDaniel Sanders2018-12-131-51/+37
| | | | | | | | | | | | | | | | | One of the GCC based bots is objecting to a vector of const EncodingAndInst's: In file included from /usr/include/c++/8/vector:64, from /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/utils/TableGen/CodeGenInstruction.h:22, from /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp:15: /usr/include/c++/8/bits/stl_vector.h: In instantiation of 'class std::vector<const {anonymous}::EncodingAndInst, std::allocator<const {anonymous}::EncodingAndInst> >': /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp:375:32: required from here /usr/include/c++/8/bits/stl_vector.h:351:21: error: static assertion failed: std::vector must have a non-const, non-volatile value_type static_assert(is_same<typename remove_cv<_Tp>::type, _Tp>::value, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/8/bits/stl_vector.h:354:21: error: static assertion failed: std::vector must have the same value_type as its allocator static_assert(is_same<typename _Alloc::value_type, _Tp>::value, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ llvm-svn: 349046
* [tblgen][disasm] Separate encodings from instructionsDaniel Sanders2018-12-131-37/+51
| | | | | | | | | | | | | | | | | | | | Summary: Separate the concept of an encoding from an instruction. This will enable the definition of additional encodings for the same instruction which can be used to support variable length instruction sets in the disassembler (and potentially assembler but I'm not working towards that right now) without causing an explosion in the number of Instruction records that CodeGen then has to pick between. Reviewers: bogner, charukcs Reviewed By: bogner Subscribers: kparzysz, llvm-commits Differential Revision: https://reviews.llvm.org/D52366 llvm-svn: 349041
* Fix MSVC build by correcting placement of declspec after r345056Daniel Sanders2018-10-231-1/+1
| | | | | | Going by the MSVC toolchains at godbolt.org, declspec comes after the template<...>. llvm-svn: 345059
* [tblgen] Allow FixedLenDecoderEmitter to use APInt-like objects as InsnTypeDaniel Sanders2018-10-231-11/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some targets have very long encodings and uint64_t isn't sufficient. uint128_t isn't portable so such targets need to use an object instead. There is one catch with this at the moment, no string of bits extracted from the encoding may exceeed 64-bits. Fields are still permitted to exceed 64-bits so long as they aren't one contiguous string of bits. If this proves to be a problem then we can modify the generation of fieldFromInstruction() calls to account for it but for now I've added an assertion for this. InsnType must either be integral or an APInt-like object that must: * Have a static const max_size_in_bits equal to the number of bits in the encoding. * be default-constructible and copy-constructible * be constructible from a uint64_t (this is the key area the interface deviates from APInt since this constructor does not take the bit width) * be constructible from an APInt (this can be private) * be convertible to uint64_t * Support the ~, &,, ==, !=, and |= operators with other objects of the same type * Support shift (<<, >>) with signed and unsigned integers on the RHS * Support put (<<) to raw_ostream& Reviewers: bogner, charukcs Subscribers: nhaehnle, llvm-commits Differential Revision: https://reviews.llvm.org/D52100 llvm-svn: 345056
* [windows] Don't inline fieldFromInstruction on WindowsStella Stamenova2018-07-251-1/+7
| | | | | | | | | | | | | | | Summary: The VS compiler (on Windows) has a bug which results in fieldFromInstruction being optimized out in some circumstances. This only happens in *release no debug info* builds that have assertions *turned off* - in all other situations the function is not inlined, so the functionality is correct. All of the bots have assertions turned on, so this path is not regularly tested. The workaround is to not inline the function on Windows - if the bug is fixed in a later release of the VS compiler, the noinline specification can be removed. The test that consistently reproduces this is Lanai v11.txt test. Reviewers: asmith, labath, zturner Subscribers: dblaikie, stella.stamenova, aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D49753 llvm-svn: 337942
* [TableGen] Increase the number of supported decoder fix-ups.Sander de Smalen2018-07-051-18/+40
| | | | | | | | | | | | | | | | The vast number of added instructions for SVE causes TableGen to fail with an assertion: Assertion `Delta < 65536U && "disassembler decoding table too large!"' This patch increases the number of supported decoder fix-ups. Reviewers: dmgreen, stoklund, petpav01 Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D48937 llvm-svn: 336334
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-26/+46
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* TableGen: Use DefInit::getDef() instead of the type's getRecord()Nicolai Haehnle2018-03-051-14/+11
| | | | | | | | | | | The former simply makes more sense: we want to access the data here in the backend, not information about the type. More importantly, removing users of RecordRecTy::getRecord() allows us more freedom to refactor the frontend. Change-Id: Iee8905fd22cdb9b11c42ca03246c03d8fe4dd77f llvm-svn: 326699
* [tablegen] Avoid creating temporary stringsAlexander Shaposhnikov2017-07-051-3/+1
| | | | | | | | | | | | | If a method / function returns a StringRef but the variable is of type const std::string& a temporary string is created (StringRef has a cast operator to std::string), which is a suboptimal behavior. Differential revision: https://reviews.llvm.org/D34994 Test plan: make check-all llvm-svn: 307195
* [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
OpenPOWER on IntegriCloud