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 | |