maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/utils/TableGen/TableGenBackends.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

100 lines
4.6 KiB
C
Raw Normal View History

Write llvm-tblgen backends as functions instead of sub-classes. The TableGenBackend base class doesn't do much, and will be removed completely soon. Patch by Sean Silva! llvm-svn: 158311
2012-06-11 23:37:55 +08:00
//===- TableGenBackends.h - Declarations for LLVM TableGen Backends -------===//
//
Update the file headers across all of the LLVM projects in the monorepo 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
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Write llvm-tblgen backends as functions instead of sub-classes. The TableGenBackend base class doesn't do much, and will be removed completely soon. Patch by Sean Silva! llvm-svn: 158311
2012-06-11 23:37:55 +08:00
//
//===----------------------------------------------------------------------===//
//
// This file contains the declarations for all of the LLVM TableGen
// backends. A "TableGen backend" is just a function. See below for a
// precise description.
//
//===----------------------------------------------------------------------===//
Canonicalize header guards into a common format. Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
2014-08-14 00:26:38 +08:00
#ifndef LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H
#define LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H
Write llvm-tblgen backends as functions instead of sub-classes. The TableGenBackend base class doesn't do much, and will be removed completely soon. Patch by Sean Silva! llvm-svn: 158311
2012-06-11 23:37:55 +08:00
// A TableGen backend is a function that looks like
//
// EmitFoo(RecordKeeper &RK, raw_ostream &OS /*, anything else you need */ )
//
// What you do inside of that function is up to you, but it will usually
// involve generating C++ code to the provided raw_ostream.
//
// The RecordKeeper is just a top-level container for an in-memory
// representation of the data encoded in the TableGen file. What a TableGen
// backend does is walk around that in-memory representation and generate
// stuff based on the information it contains.
//
// The in-memory representation is a node-graph (think of it like JSON but
// with a richer ontology of types), where the nodes are subclasses of
// Record. The methods `getClass`, `getDef` are the basic interface to
// access the node-graph. RecordKeeper also provides a handy method
// `getAllDerivedDefinitions`. Consult "include/llvm/TableGen/Record.h" for
// the exact interfaces provided by Record's and RecordKeeper.
//
// A common pattern for TableGen backends is for the EmitFoo function to
// instantiate a class which holds some context for the generation process,
// and then have most of the work happen in that class's methods. This
// pattern partly has historical roots in the previous TableGen backend API
// that involved a class and an invocation like `FooEmitter(RK).run(OS)`.
//
// Remember to wrap private things in an anonymous namespace. For most
// backends, this means that the EmitFoo function is the only thing not in
// the anonymous namespace.
// FIXME: Reorganize TableGen so that build dependencies can be more
// accurately expressed. Currently, touching any of the emitters (or
// anything that they transitively depend on) causes everything dependent
// on TableGen to be rebuilt (this includes all the targets!). Perhaps have
// a standalone TableGen binary and have the backends be loadable modules
// of some sort; then the dependency could be expressed as being on the
// module, and all the modules would have a common dependency on the
// TableGen binary with as few dependencies as possible on the rest of
// LLVM.
namespace llvm {
class raw_ostream;
class RecordKeeper;
[TableGen] Remove unused target intrinsic generation logic AMDGPU was the last in tree target to use this tablegen mode. I plan to split up the global intrinsic enum similar to the way that clang diagnostics are split up today. I don't plan to build on this mode. Reviewers: arsenm, echristo, efriedma Reviewed By: echristo Differential Revision: https://reviews.llvm.org/D71318
2019-12-11 23:37:16 +08:00
void EmitIntrinsicEnums(RecordKeeper &RK, raw_ostream &OS);
void EmitIntrinsicImpl(RecordKeeper &RK, raw_ostream &OS);
Write llvm-tblgen backends as functions instead of sub-classes. The TableGenBackend base class doesn't do much, and will be removed completely soon. Patch by Sean Silva! llvm-svn: 158311
2012-06-11 23:37:55 +08:00
void EmitAsmMatcher(RecordKeeper &RK, raw_ostream &OS);
void EmitAsmWriter(RecordKeeper &RK, raw_ostream &OS);
void EmitCallingConv(RecordKeeper &RK, raw_ostream &OS);
void EmitCodeEmitter(RecordKeeper &RK, raw_ostream &OS);
[M68k][TableGen](1/8) TableGen related changes - Add a new TableGen backend: CodeBeads - Add support to generate logical operand information For the first item, it is currently a workaround of M68k's (complex) instruction encoding. A typical architecture, especially CISC one like X86, normally uses `MCInstrDesc::TSFlags` to carry instruction encoding info. However, at the early days of M68k backend development, we found it difficult to fit every possible encoding into the 64-bit `MCInstrDesc::TSFlags`. Therefore CodeBeads was invented to provide an alternative, arbitrary length container for instruciton encoding info. However, in the long term we incline not to use a new TG backend for less common pattern like what we encountered in M68k. A bug has been created to host to discussion on migrating from CodeBeads to more concise solution: https://bugs.llvm.org/show_bug.cgi?id=48792 The second item was also served for similar purpose. It created utility functions that tell you the index of a `MachineOperand` in a `MachineInst` given a logical operand index. In normal cases a logical operand is the same as `MachineOperand`, but for operands using complex addressing mode a logical operand might be consisting of multiple `MachineOperand`. The TableGen-ed `getLogicalOperandIdx`, for instance, can give you the mapping between these two concepts. Nevertheless, we hope to remove this feature in the future if possible. Since it's not really useful for the targets supported by LLVM now either. Authors: myhsu, m4yers, glaubitz Differential Revision: https://reviews.llvm.org/D88385
2021-03-08 08:30:54 +08:00
void EmitCodeBeads(RecordKeeper &RK, raw_ostream &OS);
Write llvm-tblgen backends as functions instead of sub-classes. The TableGenBackend base class doesn't do much, and will be removed completely soon. Patch by Sean Silva! llvm-svn: 158311
2012-06-11 23:37:55 +08:00
void EmitDAGISel(RecordKeeper &RK, raw_ostream &OS);
void EmitDFAPacketizer(RecordKeeper &RK, raw_ostream &OS);
void EmitDisassembler(RecordKeeper &RK, raw_ostream &OS);
void EmitFastISel(RecordKeeper &RK, raw_ostream &OS);
void EmitInstrInfo(RecordKeeper &RK, raw_ostream &OS);
[Docs] Add tablegen backend for target opcode documentation 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
2017-11-14 23:35:15 +08:00
void EmitInstrDocs(RecordKeeper &RK, raw_ostream &OS);
Write llvm-tblgen backends as functions instead of sub-classes. The TableGenBackend base class doesn't do much, and will be removed completely soon. Patch by Sean Silva! llvm-svn: 158311
2012-06-11 23:37:55 +08:00
void EmitPseudoLowering(RecordKeeper &RK, raw_ostream &OS);
[RISCV] Tablegen-driven Instruction Compression. 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
2018-04-07 05:07:05 +08:00
void EmitCompressInst(RecordKeeper &RK, raw_ostream &OS);
Write llvm-tblgen backends as functions instead of sub-classes. The TableGenBackend base class doesn't do much, and will be removed completely soon. Patch by Sean Silva! llvm-svn: 158311
2012-06-11 23:37:55 +08:00
void EmitRegisterInfo(RecordKeeper &RK, raw_ostream &OS);
void EmitSubtarget(RecordKeeper &RK, raw_ostream &OS);
add TableGen support to create relationship maps between instructions Relationship maps are represented as InstrMapping records which are parsed by TableGen and the information is used to construct mapping tables to represent appropriate relations between instructions. These tables are emitted into XXXGenInstrInfo.inc file along with the functions to query them. Patch by Jyotsna Verma <jverma@codeaurora.org>. llvm-svn: 166685
2012-10-25 23:54:06 +08:00
void EmitMapTable(RecordKeeper &RK, raw_ostream &OS);
Copy clang/Driver/<Option parsing stuff> to llvm. llvm-svn: 169344
2012-12-05 08:29:32 +08:00
void EmitOptParser(RecordKeeper &RK, raw_ostream &OS);
[TableGen] Add backend to generate command guide for tools using libOption. 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
2019-11-23 06:07:21 +08:00
void EmitOptRST(RecordKeeper &RK, raw_ostream &OS);
Add TableGen ctags(1) emitter and helper script. 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
2013-03-22 07:40:38 +08:00
void EmitCTags(RecordKeeper &RK, raw_ostream &OS);
Move the enum attributes defined in Attributes.h to a table-gen file. 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
2015-11-12 04:35:42 +08:00
void EmitAttributes(RecordKeeper &RK, raw_ostream &OS);
AArch64: TableGenerate system instruction operands. 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
2016-07-06 05:23:04 +08:00
void EmitSearchableTables(RecordKeeper &RK, raw_ostream &OS);
[GlobalISel] Add basic Selector-emitter tblgen backend. 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
2016-12-22 07:26:20 +08:00
void EmitGlobalISel(RecordKeeper &RK, raw_ostream &OS);
[gicombiner] Add the boring boilerplate for the declarative combiner 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
2019-10-03 05:13:07 +08:00
void EmitGICombiner(RecordKeeper &RK, raw_ostream &OS);
[X86][AVX512] Adding new LLVM TableGen backend which generates the EVEX2VEX 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
2017-03-07 16:11:19 +08:00
void EmitX86EVEX2VEXTables(RecordKeeper &RK, raw_ostream &OS);
[X86][TableGen] Recommitting the X86 memory folding tables TableGen backend 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
2017-10-08 17:20:32 +08:00
void EmitX86FoldTables(RecordKeeper &RK, raw_ostream &OS);
Re-commit: [globalisel] Tablegen-erate current Register Bank Information 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
2017-01-19 19:15:55 +08:00
void EmitRegisterBank(RecordKeeper &RK, raw_ostream &OS);
[MCSched] Bind PFM Counters to the CPUs instead of the SchedModel. 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
2018-10-25 15:44:01 +08:00
void EmitExegesis(RecordKeeper &RK, raw_ostream &OS);
[TableGen] Introduce a generic automaton (DFA) backend 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
2019-10-04 17:03:36 +08:00
void EmitAutomata(RecordKeeper &RK, raw_ostream &OS);
[openmp] Move Directive and Clause helper function to tablegen Summary: Follow up to D81736. Move getOpenMPDirectiveKind, getOpenMPClauseKind, getOpenMPDirectiveName and getOpenMPClauseName to the new tablegen code generation. The code is generated in a new file named OMP.cpp.inc Reviewers: jdoerfert, jdenny, thakis Reviewed By: jdoerfert, jdenny Subscribers: mgorny, yaxunl, hiraditya, guansong, sstefan1, llvm-commits, thakis Tags: #llvm Differential Revision: https://reviews.llvm.org/D82405
2020-07-01 02:36:37 +08:00
void EmitDirectivesDecl(RecordKeeper &RK, raw_ostream &OS);
void EmitDirectivesImpl(RecordKeeper &RK, raw_ostream &OS);
Write llvm-tblgen backends as functions instead of sub-classes. The TableGenBackend base class doesn't do much, and will be removed completely soon. Patch by Sean Silva! llvm-svn: 158311
2012-06-11 23:37:55 +08:00
} // End llvm namespace
Canonicalize header guards into a common format. Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
2014-08-14 00:26:38 +08:00
#endif