xref: /freebsd/contrib/llvm-project/llvm/utils/TableGen/TableGenBackends.h (revision 56b17de1e8360fe131d425de20b5e75ff3ea897c)
1 //===- TableGenBackends.h - Declarations for LLVM TableGen Backends -------===//
2 //
3 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
4 // See https://llvm.org/LICENSE.txt for license information.
5 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
6 //
7 //===----------------------------------------------------------------------===//
8 //
9 // This file contains the declarations for all of the LLVM TableGen
10 // backends. A "TableGen backend" is just a function. See below for a
11 // precise description.
12 //
13 //===----------------------------------------------------------------------===//
14 
15 #ifndef LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H
16 #define LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H
17 
18 #include <string>
19 
20 // A TableGen backend is a function that looks like
21 //
22 //    EmitFoo(RecordKeeper &RK, raw_ostream &OS /*, anything else you need */ )
23 //
24 // What you do inside of that function is up to you, but it will usually
25 // involve generating C++ code to the provided raw_ostream.
26 //
27 // The RecordKeeper is just a top-level container for an in-memory
28 // representation of the data encoded in the TableGen file. What a TableGen
29 // backend does is walk around that in-memory representation and generate
30 // stuff based on the information it contains.
31 //
32 // The in-memory representation is a node-graph (think of it like JSON but
33 // with a richer ontology of types), where the nodes are subclasses of
34 // Record. The methods `getClass`, `getDef` are the basic interface to
35 // access the node-graph.  RecordKeeper also provides a handy method
36 // `getAllDerivedDefinitions`. Consult "include/llvm/TableGen/Record.h" for
37 // the exact interfaces provided by Record's and RecordKeeper.
38 //
39 // A common pattern for TableGen backends is for the EmitFoo function to
40 // instantiate a class which holds some context for the generation process,
41 // and then have most of the work happen in that class's methods. This
42 // pattern partly has historical roots in the previous TableGen backend API
43 // that involved a class and an invocation like `FooEmitter(RK).run(OS)`.
44 //
45 // Remember to wrap private things in an anonymous namespace. For most
46 // backends, this means that the EmitFoo function is the only thing not in
47 // the anonymous namespace.
48 
49 // FIXME: Reorganize TableGen so that build dependencies can be more
50 // accurately expressed. Currently, touching any of the emitters (or
51 // anything that they transitively depend on) causes everything dependent
52 // on TableGen to be rebuilt (this includes all the targets!). Perhaps have
53 // a standalone TableGen binary and have the backends be loadable modules
54 // of some sort; then the dependency could be expressed as being on the
55 // module, and all the modules would have a common dependency on the
56 // TableGen binary with as few dependencies as possible on the rest of
57 // LLVM.
58 
59 namespace llvm {
60 
61 class raw_ostream;
62 class RecordKeeper;
63 
64 void EmitMapTable(RecordKeeper &RK, raw_ostream &OS);
65 
66 // Defined in DecoderEmitter.cpp
67 void EmitDecoder(RecordKeeper &RK, raw_ostream &OS,
68                  const std::string &PredicateNamespace);
69 
70 } // namespace llvm
71 
72 #endif
73