summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [WebAssembly] Make disassembler always emit most canonical name.Wouter van Oortmerssen2019-02-051-5/+26
| | | | | | | | | | | | | | | | | | | | | Summary: There are a few instructions that all map to the same opcode, so when disassembling, we have to pick one. That was just the first one before (the except_ref variant in the case of "call"), now it is the one marked as IsCanonical in tablegen, or failing that, the shortest name (which is typically the "canonical" one). Also introduced a canonical "end" instruction for this purpose. Reviewers: dschuff, tlively Subscribers: sbc100, jgravelle-google, aheejin, llvm-commits, sunfish Tags: #llvm Differential Revision: https://reviews.llvm.org/D57713 llvm-svn: 353131
* [Tablegen][DAG]: Fix build breakage when LLVM_ENABLE_DAGISEL_COV=1Aditya Nandakumar2019-02-041-2/+2
| | | | | | | | | | LLVM_ENABLE_DAGISEL_COV can be used to instrument DAGISel tablegen selection code to show which patterns along with Complex patterns were used when selecting instructions. Unfortunately this is turned off by default and was broken but never tested. This required a simple fix (missing new line) to get it to build again. llvm-svn: 353091
* [X86] Print %st(0) as %st when its implicit to the instruction. Continue ↵Craig Topper2019-02-041-0/+2
| | | | | | | | printing it as %st(0) when its encoded in the instruction. This is a step back from the change I made in r352985. This appears to be more consistent with gcc and objdump behavior. llvm-svn: 353015
* [IR] Match intrinsic parameter by scalar/vectorwidthSimon Pilgrim2019-01-232-2/+2
| | | | | | | | | | | | | | This patch replaces the existing LLVMVectorSameWidth matcher with LLVMScalarOrSameVectorWidth. The matching args must be either scalars or vectors with the same number of elements, but in either case the scalar/element type can differ, specified by LLVMScalarOrSameVectorWidth. I've updated the _overflow intrinsics to demonstrate this - allowing it to return a i1 or <N x i1> overflow result, matching the scalar/vectorwidth of the other (add/sub/mul) result type. The masked load/store/gather/scatter intrinsics have also been updated to use this, although as we specify the reference type to be llvm_anyvector_ty we guarantee the mask will be <N x i1> so no change in behaviour Differential Revision: https://reviews.llvm.org/D57090 llvm-svn: 351957
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1970-280/+210
| | | | | | | | | | | | | | | | | 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
* [X86] Deduplicate static calling convention helpers for code size, NFCReid Kleckner2019-01-191-11/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Right now we include ${TGT}GenCallingConv.inc once per each instruction selection method implemented by ${TGT}: - ${TGT}ISelLowering.cpp - ${TGT}CallLowering.cpp - ${TGT}FastISel.cpp Instead, add a mechanism to tablegen for marking a particular convention as "External", which causes tablegen to emit into the ::llvm namespace, instead of as a static helper. This allows us to provide a header to forward declare it, so we can simply call the function from all the places it is referenced. Typically the calling convention analyzer is called indirectly, so it doesn't benefit from inlining. This saves a bit of final binary size, but mostly just saves object file size: before after diff artifact 12852K 12492K -360K X86ISelLowering.cpp.obj 4640K 4280K -360K X86FastISel.cpp.obj 1704K 2092K +388K X86CallingConv.cpp.obj 52448K 52336K -112K llc.exe I didn't collect before numbers for X86CallLowering.cpp.obj, which is for GlobalISel, but we should save 360K there as well. This patch applies the strategy to the X86 backend, but there is no reason it couldn't be applied to the other backends that implement multiple ISel strategies, like AArch64. Reviewers: craig.topper, hfinkel, efriedma Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D56883 llvm-svn: 351616
* [WebAssembly] Fixed disassembler not knowing about new brlist operandWouter van Oortmerssen2019-01-031-0/+1
| | | | | | | | | | | | | | Summary: The previously introduced new operand type for br_table didn't have a disassembler implementation, causing an assert. Reviewers: dschuff, aheejin Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D56227 llvm-svn: 350366
* [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
* [TableGen:AsmWriter] Cope with consecutive tied operands.Simon Tatham2018-12-141-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you define an instruction alias as a subclass of InstAlias, you specify all the MC operands for the instruction it expands to, except for operands that are tied to a previous one, which you leave out in the expectation that the Tablegen output code will fill them in automatically. But the code in Tablegen's AsmWriter backend that skips over a tied operand was doing it using 'if' instead of 'while', because it wasn't expecting to find two tied operands in sequence. So if an instruction updates a pair of registers in place, so that its MC representation has two input operands tied to the output ones (for example, Arm's UMLAL instruction), then any alias which wants to expand to a special case of that instruction is likely to fail to match, because the indices of subsequent operands will be off by one in the generated printAliasInstr function. This patch re-indents some existing code, so it's clearest when viewed as a diff with whitespace changes ignored. Reviewers: fhahn, rengolin, sdesmalen, atanasyan, asb, jholewinski, t.p.northover, kparzysz, craig.topper, stoklund Reviewed By: rengolin Subscribers: javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D53816 llvm-svn: 349141
* 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
* [TableGen] Preserve order of output operands in DAGISelMatcherGenCraig Topper2018-12-053-13/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes support in DAGISelMatcher backend for DAG nodes with multiple result values. Previously the order of results in selected DAG nodes always matched the order of results in ISel patterns. After the change the order of results matches the order of operands in OutOperandList instead. For example, given this definition from the attached test case: def INSTR : Instruction { let OutOperandList = (outs GPR:$r1, GPR:$r0); let InOperandList = (ins GPR:$t0, GPR:$t1); let Pattern = [(set i32:$r0, i32:$r1, (udivrem i32:$t0, i32:$t1))]; } the DAGISelMatcher backend currently produces a matcher that creates INSTR nodes with the first result `$r0` and the second result `$r1`, contrary to the order in the OutOperandList. The order of operands in OutOperandList does not matter at all, which is unexpected (and unfortunate) because the order of results of a DAG node does matters, perhaps a lot. With this change, if the order in OutOperandList does not match the order in Pattern, DAGISelMatcherGen emits CompleteMatch opcodes with the order of results taken from OutOperandList. Backend writers can use it to express result reorderings in TableGen. If the order in OutOperandList matches the order in Pattern, the result of DAGISelMatcherGen is unaffected. Patch by Eugene Sharygin Reviewers: andreadb, bjope, hfinkel, RKSimon, craig.topper Reviewed By: craig.topper Subscribers: nhaehnle, craig.topper, llvm-commits Differential Revision: https://reviews.llvm.org/D55055 llvm-svn: 348326
* [TableGen] Improve the formatting of the emitted predicates (NFC)Evandro Menezes2018-12-041-8/+7
| | | | llvm-svn: 348226
* [TableGen] Fix typo in emitted comment (NFC)Evandro Menezes2018-12-041-1/+1
| | | | llvm-svn: 348225
* [ARM][MC] Move information about variadic register defs into tablegenOliver Stannard2018-12-034-0/+4
| | | | | | | | | | | | | | | | | | | Currently, variadic operands on an MCInst are assumed to be uses, because they come after the defs. However, this is not always the case, for example the Arm/Thumb LDM instructions write to a variable number of registers. This adds a property of instruction definitions which can be used to mark variadic operands as defs. This only affects MCInst, because MachineInstruction already tracks use/def per operand in each instance of the instruction, so can already represent this. This property can then be checked in MCInstrDesc, allowing us to remove some special cases in ARMAsmParser::isITBlockTerminator. Differential revision: https://reviews.llvm.org/D54853 llvm-svn: 348114
* [TableGen] Fix negation of simple predicatesEvandro Menezes2018-11-301-14/+41
| | | | | | | | | | | | Simple predicates, such as those defined by `CheckRegOperandSimple` or `CheckImmOperandSimple`, were not being negated when used with `CheckNot`. This change fixes this issue by defining the previously declared methods to handle simple predicates. Differential revision: https://reviews.llvm.org/D55089 llvm-svn: 348034
* TableGen/ISel: Allow PatFrag predicate code to access captured operandsNicolai Haehnle2018-11-308-91/+281
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This simplifies writing predicates for pattern fragments that are automatically re-associated or commuted. For example, a followup patch adds patterns for fragments of the form (add (shl $x, $y), $z) to the AMDGPU backend. Such patterns are automatically commuted to (add $z, (shl $x, $y)), which makes it basically impossible to refer to $x, $y, and $z generically in the PredicateCode. With this change, the PredicateCode can refer to $x, $y, and $z simply as `Operands[i]`. Test confirmed that there are no changes to any of the generated files when building all (non-experimental) targets. Change-Id: I61c00ace7eed42c1d4edc4c5351174b56b77a79c Reviewers: arsenm, rampitec, RKSimon, craig.topper, hfinkel, uweigand Subscribers: wdng, tpr, llvm-commits Differential Revision: https://reviews.llvm.org/D51994 llvm-svn: 347992
* [TableGen] Examine entire subreg compositions to detect ambiguityKrzysztof Parzyszek2018-11-291-5/+59
| | | | | | | | | | | | | | | | When tablegen detects that there exist two subregister compositions that result in the same value for some register, it will emit a warning. This kind of an overlap in compositions should only happen when it is caused by a user-defined composition. It can happen, however, that the user- defined composition is not identically equal to another one, but it does produce the same value for one or more registers. In such cases suppress the warning. This patch is to silence the warning when building the System Z backend after D50725. Differential Revision: https://reviews.llvm.org/D50977 llvm-svn: 347894
* [llvm-mca][MC] Add the ability to declare which processor resources model ↵Andrea Di Biagio2018-11-293-2/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | load/store queues (PR36666). This patch adds the ability to specify via tablegen which processor resources are load/store queue resources. A new tablegen class named MemoryQueue can be optionally used to mark resources that model load/store queues. Information about the load/store queue is collected at 'CodeGenSchedule' stage, and analyzed by the 'SubtargetEmitter' to initialize two new fields in struct MCExtraProcessorInfo named `LoadQueueID` and `StoreQueueID`. Those two fields are identifiers for buffered resources used to describe the load queue and the store queue. Field `BufferSize` is interpreted as the number of entries in the queue, while the number of units is a throughput indicator (i.e. number of available pickers for loads/stores). At construction time, LSUnit in llvm-mca checks for the presence of extra processor information (i.e. MCExtraProcessorInfo) in the scheduling model. If that information is available, and fields LoadQueueID and StoreQueueID are set to a value different than zero (i.e. the invalid processor resource index), then LSUnit initializes its LoadQueue/StoreQueue based on the BufferSize value declared by the two processor resources. With this patch, we more accurately track dynamic dispatch stalls caused by the lack of LS tokens (i.e. load/store queue full). This is also shown by the differences in two BdVer2 tests. Stalls that were previously classified as generic SCHEDULER FULL stalls, are not correctly classified either as "load queue full" or "store queue full". About the differences in the -scheduler-stats view: those differences are expected, because entries in the load/store queue are not released at instruction issue stage. Instead, those are released at instruction executed stage. This is the main reason why for the modified tests, the load/store queues gets full before PdEx is full. Differential Revision: https://reviews.llvm.org/D54957 llvm-svn: 347857
* Fix -Winfinite-recursion compile error.Haojian Wu2018-11-281-1/+3
| | | | llvm-svn: 347749
* [TableGen] Better error checking for TIED_TO constraints.Simon Tatham2018-11-282-29/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are quite strong constraints on how you can use the TIED_TO constraint between MC operands, many of which are currently not checked until compiler run time. MachineVerifier enforces that operands can only be tied together in pairs (no three-way ties), and MachineInstr::tieOperands enforces that one of the tied operands must be an output operand (def) and the other must be an input operand (use). Now we check these at TableGen time, so that if you violate any of them in a new instruction definition, you find out immediately, instead of having to wait until you compile something that makes code generation hit one of those assertions. Also in this commit, all the error reports in ParseConstraint now include the name and source location of the def where the problem happened, so that if you do trigger any of these errors, it's easier to find the part of your TableGen input where you made the mistake. The trunk sources already build successfully with this additional error check, so I think no in-tree target has any of these problems. Reviewers: fhahn, lhames, nhaehnle, MatzeB Reviewed By: MatzeB Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53815 llvm-svn: 347743
* [TableGen] Improve readability of generated code (NFC)Evandro Menezes2018-11-271-2/+2
| | | | | | Improve the readability of the generated code for `MCOpcodeSwitchStatement`. llvm-svn: 347707
* [TableGen] Refactor macro names (NFC)Evandro Menezes2018-11-271-10/+10
| | | | | | Make the names for the macros for `TargetInstrInfo` uniform. llvm-svn: 347706
* [TableGen] Emit more variant transitionsEvandro Menezes2018-11-231-2/+15
| | | | | | | | | | | | | | | | | | | | | | `llvm-mca` relies on the predicates to be based on `MCSchedPredicate` in order to resolve the scheduling for variant instructions. Otherwise, it aborts the building of the instruction model early. However, the scheduling model emitter in `TableGen` gives up too soon, unless all processors use only such predicates. In order to allow more processors to be used with `llvm-mca`, this patch emits scheduling transitions if any processor uses these predicates. The transition emitted for the processors using legacy predicates is the one specified with `NoSchedPred`, which is based on `MCSchedPredicate`. Preferably, `llvm-mca` should instead assume a reasonable default when a variant transition is not based on `MCSchedPredicate` for a given processor. This issue should be revisited in the future. Differential revision: https://reviews.llvm.org/D54648 llvm-svn: 347504
* Mark @llvm.trap coldVedant Kumar2018-11-143-1/+16
| | | | | | | | | | | | | | | | A call to @llvm.trap can be expected to be cold (i.e. unlikely to be reached in a normal program execution). Outlining paths which unconditionally trap is an important memory saving. As the hot/cold splitting pass (imho) should not treat all noreturn calls as cold, explicitly mark @llvm.trap cold so that it can be outlined. Split out of https://reviews.llvm.org/D54244. Differential Revision: https://reviews.llvm.org/D54329 llvm-svn: 346885
* [llvm-exegesis][NFC] Add a way to declare the default counter binding for ↵Clement Courbet2018-11-091-14/+18
| | | | | | | | | | | | | | | | unbound CPUs for a target. Summary: This simplifies the code and moves everything to tablegen for consistency. This also prepares the ground for adding issue counters. Reviewers: gchatelet, john.brawn, jsji Subscribers: nemanjai, mgorny, javed.absar, kbarton, tschuett, llvm-commits Differential Revision: https://reviews.llvm.org/D54297 llvm-svn: 346489
* [WebAssembly] Read prefixed opcodes as ULEB128sThomas Lively2018-11-091-1/+5
| | | | | | | | | | | | Summary: Depends on D54126. Reviewers: aheejin, dschuff, aardappel Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D54138 llvm-svn: 346465
* TableGen: Fix ASAN errorNicolai Haehnle2018-10-311-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As a bonus, this arguably improves the code by making it simpler. gcc 8 on Ubuntu 18.10 reports the following: ==39667==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffffff8ae0 at pc 0x555555dbfc68 bp 0x7fffffff8760 sp 0x7fffffff8750 WRITE of size 8 at 0x7fffffff8ae0 thread T0 #0 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Alloc_hider::_Alloc_hider(char*, std::allocator<char>&&) /usr/include/c++/8/bits/basic_string.h:149 #1 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) /usr/include/c++/8/bits/basic_string.h:542 #2 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) /usr/include/c++/8/bits/basic_string.h:6009 #3 0x555555dbfc67 in searchableFieldType /home/nha/amd/build/san/llvm-src/utils/TableGen/SearchableTableEmitter.cpp:168 (...) Address 0x7fffffff8ae0 is located in stack of thread T0 at offset 864 in frame #0 0x555555dbef3f in searchableFieldType /home/nha/amd/build/san/llvm-src/utils/TableGen/SearchableTableEmitter.cpp:148 Reviewers: fhahn, simon_tatham, kparzysz Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53931 llvm-svn: 345749
* [tblgen][PredicateExpander] Add the ability to describe more complex ↵Andrea Di Biagio2018-10-313-18/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constraints on instruction operands. Before this patch, class PredicateExpander only knew how to expand simple predicates that performed checks on instruction operands. In particular, the new scheduling predicate syntax was not rich enough to express checks like this one: Foo(MI->getOperand(0).getImm()) == ExpectedVal; Here, the immediate operand value at index zero is passed in input to function Foo, and ExpectedVal is compared against the value returned by function Foo. While this predicate pattern doesn't show up in any X86 model, it shows up in other upstream targets. So, being able to support those predicates is fundamental if we want to be able to modernize all the scheduling models upstream. With this patch, we allow users to specify if a register/immediate operand value needs to be passed in input to a function as part of the predicate check. Now, register/immediate operand checks all derive from base class CheckOperandBase. This patch also changes where TIIPredicate definitions are expanded by the instructon info emitter. Before, definitions were expanded in class XXXGenInstrInfo (where XXX is a target name). With the introduction of this new syntax, we may want to have TIIPredicates expanded directly in XXXInstrInfo. That is because functions used by the new operand predicates may only exist in the derived class (i.e. XXXInstrInfo). This patch is a non functional change for the existing scheduling models. In future, we will be able to use this richer syntax to better describe complex scheduling predicates, and expose them to llvm-mca. Differential Revision: https://reviews.llvm.org/D53880 llvm-svn: 345714
* Use the container form llvm::sort(C)Fangrui Song2018-10-311-1/+1
| | | | llvm-svn: 345682
* [MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.Clement Courbet2018-10-258-122/+230
| | | | | | | | | | | | | | | | Summary: The pfm counters are now in the ExegesisTarget rather than the MCSchedModel (PR39165). This also compresses the pfm counter tables (PR37068). Reviewers: RKSimon, gchatelet Subscribers: mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D52932 llvm-svn: 345243
* 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
* [WebAssembly][NFC] Remove WebAssemblyStackifier TableGen backendThomas Lively2018-10-225-59/+8
| | | | | | | | | | | | | | | | Summary: Replace its functionality with a TableGen InstrInfo relational instruction mapping. Although arguably more complex than the TableGen backend, the relational mapping is a smaller maintenance burden than a TableGen backend. Reviewers: aardappel, aheejin, dschuff Subscribers: mgorny, sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D53307 llvm-svn: 344962
* Use llvm::{all,any,none}_of instead std::{all,any,none}_of. NFCFangrui Song2018-10-191-4/+3
| | | | llvm-svn: 344774
* [tblgen][llvm-mca] Add the ability to describe move elimination candidates ↵Andrea Di Biagio2018-10-123-10/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | via tablegen. This patch adds the ability to identify instructions that are "move elimination candidates". It also allows scheduling models to describe processor register files that allow move elimination. A move elimination candidate is an instruction that can be eliminated at register renaming stage. Each subtarget can specify which instructions are move elimination candidates with the help of tablegen class "IsOptimizableRegisterMove" (see llvm/Target/TargetInstrPredicate.td). For example, on X86, BtVer2 allows both GPR and MMX/SSE moves to be eliminated. The definition of 'IsOptimizableRegisterMove' for BtVer2 looks like this: ``` def : IsOptimizableRegisterMove<[ InstructionEquivalenceClass<[ // GPR variants. MOV32rr, MOV64rr, // MMX variants. MMX_MOVQ64rr, // SSE variants. MOVAPSrr, MOVUPSrr, MOVAPDrr, MOVUPDrr, MOVDQArr, MOVDQUrr, // AVX variants. VMOVAPSrr, VMOVUPSrr, VMOVAPDrr, VMOVUPDrr, VMOVDQArr, VMOVDQUrr ], CheckNot<CheckSameRegOperand<0, 1>> > ]>; ``` Definitions of IsOptimizableRegisterMove from processor models of a same Target are processed by the SubtargetEmitter to auto-generate a target-specific override for each of the following predicate methods: ``` bool TargetSubtargetInfo::isOptimizableRegisterMove(const MachineInstr *MI) const; bool MCInstrAnalysis::isOptimizableRegisterMove(const MCInst &MI, unsigned CPUID) const; ``` By default, those methods return false (i.e. conservatively assume that there are no move elimination candidates). Tablegen class RegisterFile has been extended with the following information: - The set of register classes that allow move elimination. - Maxium number of moves that can be eliminated every cycle. - Whether move elimination is restricted to moves from registers that are known to be zero. This patch is structured in three part: A first part (which is mostly boilerplate) adds the new 'isOptimizableRegisterMove' target hooks, and extends existing register file descriptors in MC by introducing new fields to describe properties related to move elimination. A second part, uses the new tablegen constructs to describe move elimination in the BtVer2 scheduling model. A third part, teaches llm-mca how to query the new 'isOptimizableRegisterMove' hook to mark instructions that are candidates for move elimination. It also teaches class RegisterFile how to describe constraints on move elimination at PRF granularity. llvm-mca tests for btver2 show differences before/after this patch. Differential Revision: https://reviews.llvm.org/D53134 llvm-svn: 344334
* [tblgen][CodeGenSchedule] Add a check for invalid RegisterFile definitions ↵Andrea Di Biagio2018-10-111-0/+5
| | | | | | with zero physical registers. llvm-svn: 344235
* TableGen/CodeGenDAGPatterns: addPredicateFn only onceNicolai Haehnle2018-10-082-9/+2
| | | | | | | | | | | | | | | | | | | | Summary: The predicate function is added in InlinePatternFragments, no need to do it here. As a result, all uses of addPredicateFn are located in InlinePatternFragments. Test confirmed that there are no changes to generated files when building all (non-experimental) targets. Change-Id: I720e42e045ca596eb0aa339fb61adf6fe71034d5 Reviewers: arsenm, rampitec, RKSimon, craig.topper, hfinkel, uweigand Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D51993 llvm-svn: 343977
* Use the container form llvm::sort(C, ...)Fangrui Song2018-09-303-28/+22
| | | | | | | There are a few leftovers in rL343163 which span two lines. This commit changes these llvm::sort(C.begin(), C.end, ...) to llvm::sort(C, ...) llvm-svn: 343426
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-278-38/+37
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [llvm-exegesis] Add support for measuring NumMicroOps.Clement Courbet2018-09-263-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Example output for vzeroall: --- mode: uops key: instructions: - 'VZEROALL' config: '' register_initial_values: cpu_name: haswell llvm_triple: x86_64-unknown-linux-gnu num_repetitions: 10000 measurements: - { debug_string: HWPort0, value: 0.0006, per_snippet_value: 0.0006, key: '3' } - { debug_string: HWPort1, value: 0.0011, per_snippet_value: 0.0011, key: '4' } - { debug_string: HWPort2, value: 0.0004, per_snippet_value: 0.0004, key: '5' } - { debug_string: HWPort3, value: 0.0018, per_snippet_value: 0.0018, key: '6' } - { debug_string: HWPort4, value: 0.0002, per_snippet_value: 0.0002, key: '7' } - { debug_string: HWPort5, value: 1.0019, per_snippet_value: 1.0019, key: '8' } - { debug_string: HWPort6, value: 1.0033, per_snippet_value: 1.0033, key: '9' } - { debug_string: HWPort7, value: 0.0001, per_snippet_value: 0.0001, key: '10' } - { debug_string: NumMicroOps, value: 20.0069, per_snippet_value: 20.0069, key: NumMicroOps } error: '' info: '' assembled_snippet: C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C5FC77C3 ... Reviewers: gchatelet Subscribers: tschuett, RKSimon, andreadb, llvm-commits Differential Revision: https://reviews.llvm.org/D52539 llvm-svn: 343094
* [globalisel][tblgen] Table optimization should consider the C++ code in C++ ↵Daniel Sanders2018-09-251-0/+6
| | | | | | | | predicates This fixes PR39045 llvm-svn: 342997
* [WebAssembly] Simplified selecting asmmatcher stack instructions.Wouter van Oortmerssen2018-09-211-10/+0
| | | | | | | | | | | | | | | | Summary: By using the existing isCodeGenOnly bit in the tablegen defs, as suggested by tlively in https://reviews.llvm.org/D51662 Tested: llvm-lit -v `find test -name WebAssembly` Reviewers: tlively Subscribers: dschuff, sbc100, jgravelle-google, aheejin, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D52373 llvm-svn: 342772
* [WebAssembly] Made assembler only use stack instruction tablegen defsWouter van Oortmerssen2018-09-211-0/+10
| | | | | | | | | | | | | | | | | | | Summary: This ensures we have the non-register version of the instruction. The stack version of call_indirect now wants a type index argument, so that has been added in the existing tests. Tested: llvm-lit -v `find test -name WebAssembly` Reviewers: dschuff Subscribers: sbc100, jgravelle-google, aheejin, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D51662 llvm-svn: 342753
* Attempt to unbreak buidlbot lld-x86_64-darwin13 after r342555.Andrea Di Biagio2018-09-191-1/+1
| | | | | | | | | | | | | | | | | | The reason why build #25777 might have failed is because the SmallVector move constructor is _not_ noexcept, and the stl implementation used by that buildbot calls _VSTD::move_if_noexcept() (according to the backtrace). OpcodeInfo has a default move constructor, and the copy constructor is deleted. However, as far as I can see, SmallVector doesn't declare a noexcept move constructor. So, what I believe it is happening here is that, _VSTD::move_if_noexcept() returns an lvalue reference and not an rvalue reference. This eventually triggers a copy that fails to compile. Hopefully, using a std::vector instead of SmallVector (as it was originally suggested by Simon in the code review) should be enough to unbreak the buildbot. llvm-svn: 342561
* [TableGen][SubtargetEmitter] Add the ability for processor models to ↵Andrea Di Biagio2018-09-195-2/+584
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | describe dependency breaking instructions. This patch adds the ability for processor models to describe dependency breaking instructions. Different processors may specify a different set of dependency-breaking instructions. That means, we cannot assume that all processors of the same target would use the same rules to classify dependency breaking instructions. The main goal of this patch is to provide the means to describe dependency breaking instructions directly via tablegen, and have the following TargetSubtargetInfo hooks redefined in overrides by tabegen'd XXXGenSubtargetInfo classes (here, XXX is a Target name). ``` virtual bool isZeroIdiom(const MachineInstr *MI, APInt &Mask) const { return false; } virtual bool isDependencyBreaking(const MachineInstr *MI, APInt &Mask) const { return isZeroIdiom(MI); } ``` An instruction MI is a dependency-breaking instruction if a call to method isDependencyBreaking(MI) on the STI (TargetSubtargetInfo object) evaluates to true. Similarly, an instruction MI is a special case of zero-idiom dependency breaking instruction if a call to STI.isZeroIdiom(MI) returns true. The extra APInt is used for those targets that may want to select which machine operands have their dependency broken (see comments in code). Note that by default, subtargets don't know about the existence of dependency-breaking. In the absence of external information, those method calls would always return false. A new tablegen class named STIPredicate has been added by this patch to let processor models classify instructions that have properties in common. The idea is that, a MCInstrPredicate definition can be used to "generate" an instruction equivalence class, with the idea that instructions of a same class all have a property in common. STIPredicate definitions are essentially a collection of instruction equivalence classes. Also, different processor models can specify a different variant of the same STIPredicate with different rules (i.e. predicates) to classify instructions. Tablegen backends (in this particular case, the SubtargetEmitter) will be able to process STIPredicate definitions, and automatically generate functions in XXXGenSubtargetInfo. This patch introduces two special kind of STIPredicate classes named IsZeroIdiomFunction and IsDepBreakingFunction in tablegen. It also adds a definition for those in the BtVer2 scheduling model only. This patch supersedes the one committed at r338372 (phabricator review: D49310). The main advantages are: - We can describe subtarget predicates via tablegen using STIPredicates. - We can describe zero-idioms / dep-breaking instructions directly via tablegen in the scheduling models. In future, the STIPredicates framework can be used for solving other problems. Examples of future developments are: - Teach how to identify optimizable register-register moves - Teach how to identify slow LEA instructions (each subtarget defining its own concept of "slow" LEA). - Teach how to identify instructions that have undocumented false dependencies on the output registers on some processors only. It is also (in my opinion) an elegant way to expose knowledge to both external tools like llvm-mca, and codegen passes. For example, machine schedulers in LLVM could reuse that information when internally constructing the data dependency graph for a code region. This new design feature is also an "opt-in" feature. Processor models don't have to use the new STIPredicates. It has all been designed to be as unintrusive as possible. Differential Revision: https://reviews.llvm.org/D52174 llvm-svn: 342555
* [TableGen] CodeGenDAGPatterns::GenerateVariants - use BitVector::set() where ↵Simon Pilgrim2018-09-191-3/+3
| | | | | | | | possible. NFCI. In these cases we are always setting to true. llvm-svn: 342543
* [TableGen] CodeGenDAGPatterns::GenerateVariants - use BitVector::push_back()Simon Pilgrim2018-09-191-2/+1
| | | | | | As mentioned on D52236, this saves 10secs in debug builds of x86 -gen-dag-isel llvm-svn: 342536
* [NFC] Update comments regarding BufferSize for ProcResources Jinsong Ji2018-09-181-1/+1
| | | | llvm-svn: 342491
OpenPOWER on IntegriCloud