summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Add backend to generate command guide for tools using libOption.Jonas Devlieghere2019-11-221-0/+2
| | | | | | | | | | | | For lldb and dsymutil, the command guide is essentially a copy of its help output generated by libOption. Making sure the two stay in sync is tedious and error prone. Given that we already generate the help from a tablegen file, we might as well generate the RST as well. This adds a tablegen backend for generating Sphinx/RST command guides from the tablegen file. Differential revision: https://reviews.llvm.org/D70610
* [TableGen] Introduce a generic automaton (DFA) backendJames Molloy2019-10-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces -gen-automata, a backend for generating deterministic finite-state automata. DFAs are already generated by the -gen-dfa-packetizer backend. This backend is more generic and will hopefully be used to implement the DFA generation (and determinization) for the packetizer in the future. This backend allows not only generation of a DFA from an NFA (nondeterministic finite-state automaton), it also emits sidetables that allow a path through the DFA under a sequence of inputs to be analyzed, and the equivalent set of all possible NFA transitions extracted. This allows a user to not just answer "can my problem be solved?" but also "what is the solution?". Clearly this analysis is more expensive than just playing a DFA forwards so is opt-in. The DFAPacketizer has this behaviour already but this is a more compact and generic representation. Examples are bundled in unittests/TableGen/Automata.td. Some are trivial, but the BinPacking example is a stripped-down version of the original target problem I set out to solve, where we pack values (actually immediates) into bins (an immediate pool in a VLIW bundle) subject to a set of esoteric constraints. Reviewers: t.p.northover Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67968 llvm-svn: 373718
* [gicombiner] Add a CodeExpander to handle C++ fragments with variable expansionDaniel Sanders2019-10-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: This will handle expansion of C++ fragments in the declarative combiner including custom predicates, and escapes into C++ to aid the migration effort. Fixed the -DLLVM_LINK_LLVM_DYLIB=ON using DISABLE_LLVM_LINK_LLVM_DYLIB when creating the library. Apparently it automatically links to libLLVM.dylib and we don't want that from tablegen. Reviewers: bogner, volkan Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68288 > llvm-svn: 373551 llvm-svn: 373651
* Revert 373551 (CodeExpander.cpp CMake issue)Kristina Brooks2019-10-031-3/+0
| | | | | | | | Fix buildbots and revert the CodeExpander commit. (See http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190930/699857.html ) llvm-svn: 373581
* Revert 373555: libLLVM+modules failure with CMake 3.10.2Kristina Brooks2019-10-031-1/+1
| | | | | | | | | This reverts rL373555. I've sent an email out regarding the issue. Commit on GitHub: https://github.com/llvm/llvm-project/commit/45f682f47129c05414d4c5ae7be851772273978f llvm-svn: 373579
* [gicombiner] Make rL373551 compatible with older cmakesDaniel Sanders2019-10-031-1/+1
| | | | | | | Newer cmakes appear to be more flexible w.r.t object libraries. Convert to a static library so that it works with older cmakes too llvm-svn: 373555
* [gicombiner] Add a CodeExpander to handle C++ fragments with variable expansionDaniel Sanders2019-10-031-0/+3
| | | | | | | | | | | | | | | | | Summary: This will handle expansion of C++ fragments in the declarative combiner including custom predicates, and escapes into C++ to aid the migration effort. Reviewers: bogner, volkan Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68288 llvm-svn: 373551
* [gicombiner] Add the boring boilerplate for the declarative combinerDaniel Sanders2019-10-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first of a series of patches extracted from a much bigger WIP patch. It merely establishes the tblgen pass and the way empty combiner helpers are declared and integrated into a combiner info. The tablegen pass takes a -combiners option to select the combiner helper that will be generated. This can be given multiple values to generate multiple combiner helpers at once. Doing so helps to minimize parsing overhead. The reason for creating a GlobalISel subdirectory in utils/TableGen is that there will be quite a lot of non-pass files (~15) by the time the patch series is done. Reviewers: volkan Subscribers: mgorny, hiraditya, simoncook, Petar.Avramovic, s.egerton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68286 llvm-svn: 373527
* [MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.Clement Courbet2018-10-251-0/+1
| | | | | | | | | | | | | | | | 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
* [WebAssembly][NFC] Remove WebAssemblyStackifier TableGen backendThomas Lively2018-10-221-1/+0
| | | | | | | | | | | | | | | | 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
* [WebAssembly] TableGen backend for stackifying instructionsThomas Lively2018-08-271-0/+1
| | | | | | | | | | | | | | | | | Summary: The new stackification backend generates the giant switch statement used to translate instructions to their stackified forms. I did this because it was more interesting than adding all the different vector versions of the various SIMD instructions to the switch statment manually. Reviewers: aardappel, aheejin, dschuff Subscribers: mgorny, sbc100, jgravelle-google, sunfish, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D51318 llvm-svn: 340781
* [RFC][Patch 1/3] Add a new class of predicates for variant scheduling classes.Andrea Di Biagio2018-05-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | This patch is the first of a sequence of three patches described by the LLVM-dev RFC "MC support for variant scheduling classes". http://lists.llvm.org/pipermail/llvm-dev/2018-May/123181.html The goal of this patch is to introduce a new class of scheduling predicates for SchedReadVariant and SchedWriteVariant. An MCSchedPredicate can be used instead of a normal SchedPredicate to model checks on the instruction (either a MachineInstr or a MCInst). Internally, an MCSchedPredicate encapsulates an MCInstPredicate definition. MCInstPredicate allows the definition of expressions with a well-known semantic, that can be used to generate code for both MachineInstr and MCInst. This is the first step toward teaching to tools like lllvm-mca how to resolve variant scheduling classes. Differential Revision: https://reviews.llvm.org/D46695 llvm-svn: 333282
* [WebAssembly] Initial Disassembler.Sam Clegg2018-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | This implements a new table-gen emitter to create tables for a wasm disassembler, and a dissassembler to use them. Comes with 2 tests, that tests a few instructions manually. Is also able to disassemble large .wasm files with objdump reasonably. Not working so well, to be addressed in followups: - objdump appears to be passing an incorrect starting point. - since the disassembler works an instruction at a time, and it is disassembling stack instruction, it has no idea of pseudo register assignments. These registers are required for the instruction printing code that follows. For now, all such registers appear in the output as $0. Patch by Wouter van Oortmerssen Differential Revision: https://reviews.llvm.org/D45848 llvm-svn: 332052
* [RISCV] Tablegen-driven Instruction Compression.Sameer AbuAsal2018-04-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a tablegen-driven Instruction Compression mechanism for generating RISCV compressed instructions (C Extension) from the expanded instruction form. This tablegen backend processes CompressPat declarations in a td file and generates all the compile-time and runtime checks required to validate the declarations, validate the input operands and generate correct instructions. The checks include validating register operands, immediate operands, fixed register operands and fixed immediate operands. Example: class CompressPat<dag input, dag output> { dag Input = input; dag Output = output; list<Predicate> Predicates = []; } let Predicates = [HasStdExtC] in { def : CompressPat<(ADD GPRNoX0:$rs1, GPRNoX0:$rs1, GPRNoX0:$rs2), (C_ADD GPRNoX0:$rs1, GPRNoX0:$rs2)>; } The result is an auto-generated header file 'RISCVGenCompressEmitter.inc' which exports two functions for compressing/uncompressing MCInst instructions, plus some helper functions: bool compressInst(MCInst& OutInst, const MCInst &MI, const MCSubtargetInfo &STI, MCContext &Context); bool uncompressInst(MCInst& OutInst, const MCInst &MI, const MCRegisterInfo &MRI, const MCSubtargetInfo &STI); The clients that include this auto-generated header file and invoke these functions can compress an instruction before emitting it, in the target-specific ASM or ELF streamer, or can uncompress an instruction before printing it, when the expanded instruction format aliases is favored. The following clients were added to implement compression\uncompression for RISCV: 1) RISCVAsmParser::MatchAndEmitInstruction: Inserted a call to compressInst() to compresses instructions parsed by llvm-mc coming from an ASM input. 2) RISCVAsmPrinter::EmitInstruction: Inserted a call to compressInst() to compress instructions that were lowered from Machine Instructions (MachineInstr). 3) RVInstPrinter::printInst: Inserted a call to uncompressInst() to print the expanded version of the instruction instead of the compressed one (e.g, add s0, s0, a5 instead of c.add s0, a5) when -riscv-no-aliases is not passed. This patch squashes D45119, D42780 and D41932. It was reviewed in smaller patches by asb, efriedma, apazos and mgrang. Reviewers: asb, efriedma, apazos, llvm-commits, sabuasal Reviewed By: sabuasal Subscribers: mgorny, eraman, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, niosHD, kito-cheng, shiva0217, zzheng Differential Revision: https://reviews.llvm.org/D45385 llvm-svn: 329455
* TableGen: Allow setting SDNodeProperties on intrinsicsMatt Arsenault2017-12-201-0/+1
| | | | | | | | | | | | | | | | | Allows preserving MachineMemOperands on intrinsics through selection. For reasons I don't understand, this is a static property of the pattern and the selector deliberately goes out of its way to drop if not present. Intrinsics already inherit from SDPatternOperator allowing them to be used directly in instruction patterns. SDPatternOperator has a list of SDNodeProperty, but you currently can't set them on the intrinsic. Without SDNPMemOperand, when the node is selected any memory operands are always dropped. Allowing setting this on the intrinsics avoids needing to introduce another equivalent target node just to have SDNPMemOperand set. llvm-svn: 321212
* [Docs] Add tablegen backend for target opcode documentationOliver Stannard2017-11-141-0/+1
| | | | | | | | | | This is a tablegen backend to generate documentation for the opcodes that exist for each target. For each opcode, it lists the assembly string, the names and types of all operands, and the flags and predicates that apply to the opcode. Differential revision: https://reviews.llvm.org/D31025 llvm-svn: 318155
* Move the llvm-tblgen project into the Tablegenning folder on IDEs like ↵Aaron Ballman2017-11-041-0/+1
| | | | | | Visual Studio rather than leave it in the root directory. NFC. llvm-svn: 317420
* [X86][TableGen] Recommitting the X86 memory folding tables TableGen backend ↵Ayman Musa2017-10-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | while disabling it by default. After the original commit ([[ https://reviews.llvm.org/rL304088 | rL304088 ]]) was reverted, a discussion in llvm-dev was opened on 'how to accomplish this task'. In the discussion we concluded that the best way to achieve our goal (which is to automate the folding tables and remove the manually maintained tables) is: # Commit the tablegen backend disabled by default. # Proceed with an incremental updating of the manual tables - while checking the validity of each added entry. # Repeat previous step until we reach a state where the generated and the manual tables are identical. Then we can safely remove the manual tables and include the generated tables instead. # Schedule periodical (1 week/2 weeks/1 month) runs of the pass: - if changes appear (new entries): - make sure the entries are legal - If they are not, mark them as illegal to folding - Commit the changes (if there are any). CMake flag added for this purpose is "X86_GEN_FOLD_TABLES". Building with this flags will run the pass and emit the X86GenFoldTables.inc file under build/lib/Target/X86/ directory which is a good reference for any developer who wants to take part in the effort of completing the current folding tables. Differential Revision: https://reviews.llvm.org/D38028 llvm-svn: 315173
* TableGen support for parameterized register class informationKrzysztof Parzyszek2017-09-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This replaces TableGen's type inference to operate on parameterized types instead of MVTs, and as a consequence, some interfaces have changed: - Uses of MVTs are replaced by ValueTypeByHwMode. - EEVT::TypeSet is replaced by TypeSetByHwMode. This affects the way that types and type sets are printed, and the tests relying on that have been updated. There are certain users of the inferred types outside of TableGen itself, namely FastISel and GlobalISel. For those users, the way that the types are accessed have changed. For typical scenarios, these replacements can be used: - TreePatternNode::getType(ResNo) -> getSimpleType(ResNo) - TreePatternNode::hasTypeSet(ResNo) -> hasConcreteType(ResNo) - TypeSet::isConcrete -> TypeSetByHwMode::isValueTypeByHwMode(false) For more information, please refer to the review page. Differential Revision: https://reviews.llvm.org/D31951 llvm-svn: 313271
* [x86] Revert the X86FoldTablesEmitter due to more miscompiles.Chandler Carruth2017-06-061-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In testing, we've found yet another miscompile caused by the new tables. And this one is even less clear how to fix (we could teach it to fold a 16-bit load instead of the 32-bit load it wants, or block folding entirely). Also, the approach to excluding instructions seems increasingly to not scale well. I have left a more detailed analysis on the review log for the original patch (https://reviews.llvm.org/D32684) along with suggested path forward. I will land an additional test case that I wrote which covers the code that was miscompiling (folding into the output of `pextrw`) in a subsequent commit to keep this a pure revert. For each commit reverted here, I've restricted the revert to the non-test code touching the x86 fold table emission until the last commit where I did revert the test updates. This means the *new* test cases added for `insertps` and `xchg` remain untouched (and continue to pass). Reverted commits: r304540: [X86] Don't fold into memory operands into insertps in the ... r304347: [TableGen] Adapt more places to getValueAsString now ... r304163: [X86] Don't fold away the memory operand of an xchg. r304123: Don't capture a temporary std::string in a StringRef. r304122: Resubmit "[X86] Adding new LLVM TableGen backend that ..." Original commit was in r304088, and after a string of fixes was reverted previously in r304121 to fix build bots, and then re-landed in r304122. llvm-svn: 304762
* Resubmit "[X86] Adding new LLVM TableGen backend that generates the X86 ↵Zachary Turner2017-05-291-0/+1
| | | | | | | | | | | | | backend memory folding tables." This was reverted due to buildbot breakages and I was not familiar with this code to investigate it. But while trying to get a useful backtrace for the author, it turns out the fix was very obvious. Resubmitting this patch as is, and will submit the fix in a followup so that the fix is not hidden in the larger CL. llvm-svn: 304122
* Revert "[X86] Adding new LLVM TableGen backend that generates the X86 ↵Zachary Turner2017-05-291-1/+0
| | | | | | | | | | | | | backend memory folding tables." This reverts commit 28cb1003507f287726f43c771024a1dc102c45fe as well as all subsequent followups. llvm-tblgen currently segfaults with this change, and it seems it has been broken on the bots all day with no fixes in preparation. See, for example: http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/ llvm-svn: 304121
* [X86] Adding new LLVM TableGen backend that generates the X86 backend memory ↵Ayman Musa2017-05-281-0/+1
| | | | | | | | | | | folding tables. X86 backend holds huge tables in order to map between the register and memory forms of each instruction. This TableGen Backend automatically generated all these tables with the appropriate flags for each entry. Differential Revision: https://reviews.llvm.org/D32684 llvm-svn: 304088
* [X86][AVX512] Adding new LLVM TableGen backend which generates the EVEX2VEX ↵Ayman Musa2017-03-071-0/+1
| | | | | | | | | | | | compressing tables. X86EvexToVex machine instruction pass compresses EVEX encoded instructions by replacing them with their identical VEX encoded instructions when possible. It uses manually supported 2 large tables that map the EVEX instructions to their VEX ideticals. This TableGen backend replaces the tables by automatically generating them. Differential Revision: https://reviews.llvm.org/D30451 llvm-svn: 297127
* Re-commit: [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Adds a RegisterBank tablegen class that can be used to declare the register banks and an associated tablegen pass to generate the necessary code. Changes since first commit attempt: * Added missing guards * Added more missing guards * Found and fixed a use-after-free bug involving Twine locals Reviewers: t.p.northover, ab, rovka, qcolombet Reviewed By: qcolombet Subscribers: aditya_nandakumar, rengolin, kristof.beyls, vkalintiris, mgorny, dberris, llvm-commits, rovka Differential Revision: https://reviews.llvm.org/D27338 llvm-svn: 292478
* Re-revert: [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-181-1/+0
| | | | | | | More missing guards. My build didn't notice it due to a stale file left over from a Global ISel build. llvm-svn: 292369
* Re-commit: [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Adds a RegisterBank tablegen class that can be used to declare the register banks and an associated tablegen pass to generate the necessary code. Changes since last commit: The new tablegen pass is now correctly guarded by LLVM_BUILD_GLOBAL_ISEL and this should fix the buildbots however it may not be the whole fix. The previous buildbot failures suggest there may be a memory bug lurking that I'm unable to reproduce (including when using asan) or spot in the source. If they re-occur on this commit then I'll need assistance from the bot owners to track it down. Reviewers: t.p.northover, ab, rovka, qcolombet Reviewed By: qcolombet Subscribers: aditya_nandakumar, rengolin, kristof.beyls, vkalintiris, mgorny, dberris, llvm-commits, rovka Differential Revision: https://reviews.llvm.org/D27338 llvm-svn: 292367
* Revert r292132: [globalisel] Tablegen-erate current Register Bank ↵Daniel Sanders2017-01-161-1/+0
| | | | | | | | | Information'... Several buildbots encountered a crash in tablegen when building this commit. Reverting while I investigate the cause. llvm-svn: 292136
* [globalisel] Tablegen-erate current Register Bank InformationDaniel Sanders2017-01-161-0/+1
| | | | | | | | | | | | | | Summary: Adds a RegisterBank tablegen class that can be used to declare the register banks and an associated tablegen pass to generate the necessary code. Reviewers: t.p.northover, ab, rovka, qcolombet Subscribers: aditya_nandakumar, rengolin, kristof.beyls, vkalintiris, mgorny, dberris, llvm-commits, rovka Differential Revision: https://reviews.llvm.org/D27338 llvm-svn: 292132
* [GlobalISel] Add basic Selector-emitter tblgen backend.Ahmed Bougacha2016-12-211-0/+1
| | | | | | | | | | | | | | | | | This adds a basic tablegen backend that analyzes the SelectionDAG patterns to find simple ones that are eligible for GlobalISel-emission. That's similar to FastISel, with one notable difference: we're not fed ISD opcodes, so we need to map the SDNode operators to generic opcodes. That's done using GINodeEquiv in TargetGlobalISel.td. Otherwise, this is mostly boilerplate, and lots of filtering of any kind of "complicated" pattern. On AArch64, this is sufficient to match G_ADD up to s64 (to ADDWrr/ADDXrr) and G_BR (to B). Differential Revision: https://reviews.llvm.org/D26878 llvm-svn: 290284
* [tablegen] Merge duplicate definitions of getMinimalTypeForRange. NFC.Daniel Sanders2016-11-191-0/+1
| | | | | | | | | | | | Summary: Depends on D25614 Reviewers: qcolombet Subscribers: qcolombet, beanz, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D25617 llvm-svn: 287438
* [tablegen] Extract portions of AsmMatcherEmitter for re-use by another ↵Daniel Sanders2016-11-151-0/+1
| | | | | | | | | | | | | | | | | | | generator. NFC. Summary: This change is preparation for a change that will allow targets to verify that the instructions they emit meet the predicates they specify. This is useful to ensure that C++ legalization/lowering/instruction-selection doesn't incorrectly select code for a different subtarget than intended. Such cases are not caught by the integrated assembler when emitting instructions directly to an object file. Reviewers: qcolombet Subscribers: qcolombet, beanz, mgorny, llvm-commits, modocache Differential Revision: https://reviews.llvm.org/D25614 llvm-svn: 286945
* AArch64: TableGenerate system instruction operands.Tim Northover2016-07-051-0/+1
| | | | | | | | | | | | | | | | | | | | The way the named arguments for various system instructions are handled at the moment has a few problems: - Large-scale duplication between AArch64BaseInfo.h and AArch64BaseInfo.cpp - That weird Mapping class that I have no idea what I was on when I thought it was a good idea. - Searches are performed linearly through the entire list. - We print absolutely all registers in upper-case, even though some are canonically mixed case (SPSel for example). - The ARM ARM specifies sysregs in terms of 5 fields, but those are relegated to comments in our implementation, with a slightly opaque hex value indicating the canonical encoding LLVM will use. This adds a new TableGen backend to produce efficiently searchable tables, and switches AArch64 over to using that infrastructure. llvm-svn: 274576
* Move the enum attributes defined in Attributes.h to a table-gen file.Akira Hatanaka2015-11-111-0/+1
| | | | | | | | | | | | | | This is a step towards consolidating some of the information regarding attributes in a single place. This patch moves the enum attributes in Attributes.h to the table-gen file. Additionally, it adds definitions of target independent string attributes that will be used in follow-up commits by the inliner to check attribute compatibility. rdar://problem/19836465 llvm-svn: 252796
* Move SetTheory from utils/TableGen into lib/TableGen so Clang can use it.James Molloy2014-06-171-1/+0
| | | | llvm-svn: 211100
* Remove TGValueTypes.cpp from CMakeLists.txt which I forgot to do in r200036.Craig Topper2014-01-241-1/+0
| | | | llvm-svn: 200037
* Add TableGen ctags(1) emitter and helper script.Sean Silva2013-03-211-0/+1
| | | | | | | | | | | | | | | | | | | | | To use this in conjunction with exuberant ctags to generate a single combined tags file, run tblgen first and then $ ctags --append [...] Since some identifiers have corresponding definitions in C++ code, it can be useful (if using vim) to also use cscope, and :set cscopetagorder=1 so that :tag X will preferentially select the tablegen symbol, while :cscope find g X will always find the C++ symbol. Patch by Kevin Schoedel! (a couple small formatting changes courtesy of clang-format) llvm-svn: 177682
* Remove edis - the enhanced disassembler. Fixes PR14654.Roman Divacky2012-12-191-1/+0
| | | | llvm-svn: 170578
* Copy clang/Driver/<Option parsing stuff> to llvm.Michael J. Spencer2012-12-051-0/+1
| | | | llvm-svn: 169344
* Remove exception handling usage from tblgen.Joerg Sonnenberger2012-10-251-1/+0
| | | | | | | | | | | 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
* llvm/utils/TableGen/CMakeLists.txt: Update corresponding to r166685.NAKAMURA Takumi2012-10-251-0/+1
| | | | llvm-svn: 166686
* tblgen: Compile TableGen without RTTI.Sean Silva2012-10-101-1/+0
| | | | | | TableGen no longer needs RTTI! llvm-svn: 165651
* I'm introducing a new machine model to simultaneously allow simpleAndrew Trick2012-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | subtarget CPU descriptions and support new features of MachineScheduler. MachineModel has three categories of data: 1) Basic properties for coarse grained instruction cost model. 2) Scheduler Read/Write resources for simple per-opcode and operand cost model (TBD). 3) Instruction itineraties for detailed per-cycle reservation tables. These will all live side-by-side. Any subtarget can use any combination of them. Instruction itineraries will not change in the near term. In the long run, I expect them to only be relevant for in-order VLIW machines that have complex contraints and require a precise scheduling/bundling model. Once itineraries are only actively used by VLIW-ish targets, they could be replaced by something more appropriate for those targets. This tablegen backend rewrite sets things up for introducing MachineModel type #2: per opcode/operand cost model. llvm-svn: 159891
* Move llvm-tblgen's StringMatcher into the TableGen library so it canDouglas Gregor2012-05-021-1/+0
| | | | | | be used by clang-tblgen. llvm-svn: 156000
* Update tblgen command guide. Remove unused tblgen InstrEnumEmitter files.Craig Topper2012-02-271-1/+0
| | | | llvm-svn: 151513
* Fix up the CMake build for the new files added in r146960, they'reChandler Carruth2011-12-201-0/+1
| | | | | | likely to stay either way that discussion ends up resolving itself. llvm-svn: 146966
* TableGen: fix CMake build s'moreDylan Noblesmith2011-12-011-0/+1
| | | | | | Oops, missed another missing file from r145629. llvm-svn: 145636
* Remove this from the CMake build since I erased the file.Owen Anderson2011-11-101-1/+0
| | | | llvm-svn: 144245
* The TableGen parts of the CMake build are seriously broken. This fixesChandler Carruth2011-11-021-0/+1
| | | | | | | | | | | | | | one aspect of them by having them use the (annoying, if not broken) proper library dependency model for adding the LLVMTableGen library as a dependency. This could manifest as a link order issue in the presence of separate LLVM / Clang source builds with CMake and a linker that really cares about such things. Also, add the Support dependency to llvm-tblgen itself so that it doesn't rely on TableGen's transitive Support dependency. A parallel change for clang-tblgen will be forthcoming. llvm-svn: 143531
* Remove the Clang tblgen backends from LLVM.Peter Collingbourne2011-10-061-6/+0
| | | | llvm-svn: 141293
OpenPOWER on IntegriCloud