1//===- TableGenBackends.h - Declarations for LLVM TableGen Backends -------===//
3//                     The LLVM Compiler Infrastructure
5// This file is distributed under the University of Illinois Open Source
6// License. See LICENSE.TXT for details.
10// This file contains the declarations for all of the LLVM TableGen
11// backends. A "TableGen backend" is just a function. See below for a
12// precise description.
17// A TableGen backend is a function that looks like
19//    EmitFoo(RecordKeeper &RK, raw_ostream &OS /*, anything else you need */ )
21// What you do inside of that function is up to you, but it will usually
22// involve generating C++ code to the provided raw_ostream.
24// The RecordKeeper is just a top-level container for an in-memory
25// representation of the data encoded in the TableGen file. What a TableGen
26// backend does is walk around that in-memory representation and generate
27// stuff based on the information it contains.
29// The in-memory representation is a node-graph (think of it like JSON but
30// with a richer ontology of types), where the nodes are subclasses of
31// Record. The methods `getClass`, `getDef` are the basic interface to
32// access the node-graph.  RecordKeeper also provides a handy method
33// `getAllDerivedDefinitions`. Consult "include/llvm/TableGen/Record.h" for
34// the exact interfaces provided by Record's and RecordKeeper.
36// A common pattern for TableGen backends is for the EmitFoo function to
37// instantiate a class which holds some context for the generation process,
38// and then have most of the work happen in that class's methods. This
39// pattern partly has historical roots in the previous TableGen backend API
40// that involved a class and an invocation like `FooEmitter(RK).run(OS)`.
42// Remember to wrap private things in an anonymous namespace. For most
43// backends, this means that the EmitFoo function is the only thing not in
44// the anonymous namespace.
47// FIXME: Reorganize TableGen so that build dependencies can be more
48// accurately expressed. Currently, touching any of the emitters (or
49// anything that they transitively depend on) causes everything dependent
50// on TableGen to be rebuilt (this includes all the targets!). Perhaps have
51// a standalone TableGen binary and have the backends be loadable modules
52// of some sort; then the dependency could be expressed as being on the
53// module, and all the modules would have a common dependency on the
54// TableGen binary with as few dependencies as possible on the rest of
55// LLVM.
58namespace llvm {
60class raw_ostream;
61class RecordKeeper;
63void EmitIntrinsics(RecordKeeper &RK, raw_ostream &OS, bool TargetOnly = false);
64void EmitAsmMatcher(RecordKeeper &RK, raw_ostream &OS);
65void EmitAsmWriter(RecordKeeper &RK, raw_ostream &OS);
66void EmitCallingConv(RecordKeeper &RK, raw_ostream &OS);
67void EmitCodeEmitter(RecordKeeper &RK, raw_ostream &OS);
68void EmitDAGISel(RecordKeeper &RK, raw_ostream &OS);
69void EmitDFAPacketizer(RecordKeeper &RK, raw_ostream &OS);
70void EmitDisassembler(RecordKeeper &RK, raw_ostream &OS);
71void EmitFastISel(RecordKeeper &RK, raw_ostream &OS);
72void EmitInstrInfo(RecordKeeper &RK, raw_ostream &OS);
73void EmitPseudoLowering(RecordKeeper &RK, raw_ostream &OS);
74void EmitRegisterInfo(RecordKeeper &RK, raw_ostream &OS);
75void EmitSubtarget(RecordKeeper &RK, raw_ostream &OS);
76void EmitMapTable(RecordKeeper &RK, raw_ostream &OS);
77void EmitOptParser(RecordKeeper &RK, raw_ostream &OS);
78void EmitCTags(RecordKeeper &RK, raw_ostream &OS);
80} // End llvm namespace